Nightlife夜遊び店舗 評価スコアページ用 cron標準オートメーション依頼文テンプレート v5（2026-05-17）

Nightlife夜遊び店舗用オートメーション依頼文テンプレートの最新版。

今回の反映点

• 全記事共通の冒頭構成Gateを追加。
• ThinkMarkets型のH1、評価スコア表、リード文、右寄せ公式テキストリンク、最初のH2を固定。
• 改善担当ハンドオフ枠（9-A/9-B/10）を追加。
• 外部AI未整備時はCodex別スレッド/専門タスクへ渡せるように整理。
• handed_offかつlock中の本文を返却前に主観リライトしないルールを追加。
• ローカルSQLite不存在だけで止まらないMain Hub優先運用を明記。

共通前提

• Main Hubを正本にする。Standby Hubはreadonly、Googleスプレッドシート/Apps Script/Google承認には戻らない。
• ローカルPC内の storage/data/358-hub.sqlite が無いだけで止まらない。Main Hub Web、agent_pack、Work Queue、References、FactChecks、hub_table_upsert相当の利用可能手段を優先する。
• 認証情報、APIキー、パスワード、トークン、WordPress REST認証情報の中身は表示しない。
• 通常の.mdログ、記事本文、キュー、投稿結果の更新ではapply_patchを使わない。承認が出にくい安全な書き込み手段を使う。
• PHP/JS/CSS等の本番コード編集、ファイル削除、移動、上書き、外部公開先の新規追加、認証情報、権限変更は停止して確認する。
• 公開投稿そのものは停止条件ではない。止めるのは未承認、未検査、危険操作、GATE失敗の場合だけ。
• 0-A/0-Bなどの棚処理は複数候補を扱ってよい。1回1記事制限は制作cron、高品質テストcron、訂正cron、改善担当ハンドオフcronに適用する。
• automation名は `【サイト名＋評価スコアページ種別】タスク順番 cron 内容` の形で登録する。
• 各cronを作る時は、対象レポート記事の各項目にある新スレ起動文を先に貼り、専用スレッドとして状態復元してからautomationを作成する。
• Main Hubが401/403/invalid token/token expired/timeout/DNS/network error等で読めない場合、その回は対象なし、FAILなし、PASS、完了と判断しない。必ず `BLOCKED_HUB_AUTH / Hub認証不備 / 正本未確認 / 記事修正なし` と報告する。
• Hub正本を読めない状態で、公開、修正、301、Hub更新、PASS/FAIL確定を行わない。
• 全評価ページ共通で、冒頭はH1タイトル → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2の順にする。
• 公式テキストリンクは、アフィリエイトリンクがある場合はアフィリエイトリンク、無い場合は公式リンクにする。
• 公式テキストリンクはPC表示で本文右側または右寄せに置く。読者が本文導線として見つけられる位置にする。
• 参照例は https://invest358.com/ja/thinkmarkets-review/ とする。完全コピーではなく、冒頭構成と導線を継承する。
• H1重複、H1へのSEOタイトル混入、評価表の順序崩れ、公式リンク漏れ、コード露出、言語不一致はFAIL。
• 日本語ページは常体を基本にする。ただし偉そうにせず、落ち着いた説明文にする。対象ページの言語に合わせて基本表/補足情報も同じ言語で書く。
• 装飾は既存良質記事を継承する。太字、太字+黄色アンダー、赤太字、✅、⚠️、Cocoon系ボックスを必要箇所へ自然に入れる。
• 9-Aで文章QA/共起語改善候補を抽出し、9-Bで改善担当へ渡し、10で返却反映と硬いGate確認を行う。
• improvement_status、improvement_owner、improvement_lockを記録する。handed_offかつlock中の本文を返却前に主観リライトしない。
• Nightlife夜遊び店舗は、H1は店舗/サービス名のみ。SEOタイトルは「店舗名 + 評価・評判・レビュー」系KWを含める。
• 最寄り駅、営業時間、料金目安、予約/問い合わせ、決済方法、対応エリアは公式または補助根拠を調べて書く。
• 公式で要確認などの空欄逃げを本文/表/Directory Core値に残したらFAIL。断定できない場合は根拠と不確実性を整理する。

頻度まとめ

24時間スケジュール例

コピー用依頼文

Nightlife夜遊び店舗用 収集cron

automation名: 【Nightlife夜遊び店舗評価スコアページ】0-A cron 候補収集

Nightlife夜遊び店舗用 収集cron 新スレ起動文

コピー

# 【Nightlife夜遊び店舗評価スコアページ】0-A cron 候補収集 新スレ起動文

このスレッドは、以下のautomationだけを作成・運用する専用スレッドです。
1スレッドにheartbeatは1つだけなので、他のcron用途を混ぜないでください。
cron automationの場合も、このサイト別cron統括スレッド内で、このcron作成依頼として扱ってください。

作成するautomation名:
【Nightlife夜遊び店舗評価スコアページ】0-A cron 候補収集

対象:
Nightlife / 夜遊び店舗 / nightlife-directory-review-ja

区分:
cron

起動時間:
JST 02:10

頻度:
1日1回 / 1回最大10件

目的:
夜遊び店舗候補の0-A在庫を補充する。

最初に確認するもの:
- Main Hub: https://hub.goudou-358.jp
- 対象レポート: https://report.goudou-358.jp/nightlife-store-automation-request-templates-20260517/
- CODE-YUKI作業室: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI
- CODE-YUKI引継ぎ控え: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI\handoffs\2026-05-17_global_opening_gate_external_hb_handoff.md
- 外部HB起動文控え: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI\handoffs\2026-05-17_external_improvement_hb_startup_prompt.md
- オートポスト支社共有: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common
- branch_common保険控え: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common\manuals\first-development-source-copies\2026-05-17-global-opening-improvement-gate\global-opening-improvement-handoff.md
- Nightlife正本: Main Hub / workflow_id=nightlife-directory-review-ja
- Nightlife共通台帳: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common\ledgers\directory-core\directory-article-input-ledger.md
- Nightlife辞書セット共通台帳: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common\ledgers\directory-core\directory-set-template-registry.md
- Nightlifeローカル保険控え: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common\manuals\first-development-source-copies
- Nightlife専用サイト部フォルダが未分離の場合は、Main Hub正本とCODE-YUKI作業室を優先する。

必ず守ること:
- automation作成時の名前は、上記のautomation名をそのまま使う。
- Main Hubを正本にし、agent_pack / Work Queue / References / FactChecks / Rules / Manualsを確認してから動く。
- ローカルPC内の storage/data/358-hub.sqlite が無いだけで停止しない。
- 認証情報、APIキー、パスワード、トークン、WordPress REST認証情報の中身を読まない・表示しない。
- 通常の.mdログ、記事本文、キュー、投稿結果の更新ではapply_patchを使わない。
- GATE失敗、未承認、危険操作、認証情報、権限変更、ファイル削除/移動/上書き、本番コード編集は停止して確認する。
- Hubが401/403/invalid token等で読めない場合は、対象なし扱いにしない。`BLOCKED_HUB_AUTH / Hub認証不備 / 正本未確認 / 記事修正なし` と報告する。

全記事共通Gate:
- 冒頭構成は H1タイトル → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2。
- 公式テキストリンクは、アフィリエイトリンクがある場合はアフィリエイトリンク、無い場合は公式リンク。
- 公式テキストリンクはPC表示で本文右側または右寄せ。
- 参照例: https://invest358.com/ja/thinkmarkets-review/
- H1重複、コード露出、公式で要確認などの仮置き、言語不一致、装飾不足はFAIL。

この内容でautomationを作成してください。
作成後は、automation名、区分、起動時間、対象、初回実行で確認するHub項目を報告してください。

全評価ページ共通 / task10・8・9-A/9-B 訂正対象取得Gate（2026-05-17追記）:
- `task10/FAILキュー` という名前だけを見て0件判定しない。
- Main HubのWork Queue / Tasks、References、FactChecks、9-A/9-Bのreturned状態を横断して確認する。
- Referencesの `use_status=correction_queue`、`public_qa_handoff`、`quality_fail`、`correction_required`、または `check_status=ready/fail/failed` を訂正対象として見る。
- FactChecksの `fact_check_id`、`check_status`、`notes` に `fail` / `FAIL` / `Gate failed` / `Gate失敗` / `要修正` があるものを拾う。
- workflow共通の `article_key` だけに限定せず、記事別key、slug別key、移行記事keyも同じsite/workflow/domain内なら拾う。
- agent_packに他サイトのFAILが混在して見える場合は、対象site / workflow / domain / article_typeで絞り込み、別サイトのFAILを自分の訂正対象にしない。
- 上記を確認せずに「FAILキュー0件」「対象なし」「記事修正なし」「301対応なし」「PASS/完了」と報告しない。
- Hubが401/403/invalid token/token expired/timeout/DNS/network errorで読めない場合は、対象なし扱いにせず `BLOCKED_HUB_AUTH / Hub認証不備 / 正本未確認 / 記事修正なし` と報告する。

全評価ページ共通 / 公開本文境界Gate（2026-05-17追記）:
- 公開本文には、読者のサービス判断に必要な情報だけを書く。
- 301、リダイレクト、旧URL、旧記事、新辞書記事、移行、公開QA、Gate、PASS、FAIL、Hub、Work Queue、References、FactChecks、agent_pack、heartbeat、cron、automation、タスク番号、制作パック、台帳、作業ログを本文に書かない。
- 「この制作cronでは301を実行しない」「別工程で旧URLからの301を扱う」「辞書記事では整理する」など、作業工程の説明を本文に出さない。
- これらは内部ログ、Hub、台帳、QA記録にだけ残す。
- 公開本文では、サービス内容、料金、無料範囲、年齢制限、登録、決済、退会、安全面、注意点、公式リンクなど読者向け情報へ書き換える。
- 本文・見出し・表・FAQ・CTA周辺に内部運用語があればFAILとし、公開継続または301実行前に修正する。

全評価ページ共通 / 検索意図・上位傾向・共起語整理Gate（2026-05-17追記）:
- 公式情報と参照URL検証が終わった後、1-C記事制作パック前に `1-B2 検索意図・上位傾向・共起語整理` を行う。
- 整理するものは、読者の主要検索意図、上位記事でよく扱われる論点、自然に使えそうな共起語、使わない語、H2/H3・評価表・FAQ・リード文への反映案。
- 共起語は本文へ機械的に詰め込むノルマではない。読者理解を助ける範囲で自然に使う。
- 公式情報と矛盾する上位傾向、サービス内容と関係が薄い語、根拠不足の語は採用しない。
- 1-C制作パックには「自然使用候補」「使わない語」「構成への反映案」を分けて残す。
- 8高品質テストと9-A改善候補抽出では、このメモを見て「不足」「過剰」「不自然な詰め込み」「無関係語の混入」を確認する。

Task10本文修正・終了状態Gate（2026-05-17追加）:
- FAIL原因が本文、FAQ、冒頭構成にある場合、第一手はWordPress本文修正にする。
- Cocoon設定、page_type、テーマ設定、広告/PR表示設定などの設定側変更は補助手段。H1重複、表示崩れ、評価表欠落、本文順序崩れのリスクが出た時点で撤回し、本文修正ルートへ戻る。
- 設定側を触って失敗しただけで本文修正せずに終了しない。
- 内部作業文を公開本文から削除する。
- FAQ内の内部作業設問を削除し、必要なら読者向けFAQへ置き換える。例: 「旧記事から301してよいか」「この制作cronでは301を実行しない」「公開QAが通ったあと」は削除対象。
- 冒頭順を H1 → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2 に整える。
- 公開HTMLでH1重複、コード露出、内部作業語、評価表、公式リンク、canonical、noindexを再確認する。
- PASS後にだけ301可否へ進む。PASS前に旧URLから301しない。
- 1回のcronでは1記事だけ処理する。同じ失敗ルートを繰り返さない。
- 作業は必ず PASS / FAIL_REQUEUED / BLOCKED_HUB_AUTH / BLOCKED_WP_AUTH / BLOCKED_WP_WRITE / BLOCKED_LAYOUT_RISK / BLOCKED_MISSING_TARGET のいずれかで終了する。ローディングし続けない。

評価項目本文化・FAQ qa-box・装飾バランスGate（2026-05-17追加）:
- 評価スコア表の各項目は、本文内でH2またはH3見出しとして扱い、スコア理由、読者が確認すべき点、向いている人/注意点を書く。表だけで終わらせない。
- 評価項目名と本文見出し名は、完全一致または読者が同じ項目だと分かる名前にする。評価項目の説明が無い場合は本文ボリューム不足としてFAIL。
- 本文FAQは `<details class="qa-box"><summary>質問文</summary><div class="qa-answer">回答文</div></details>` を標準にする。
- FAQPage JSON-LDは `Schema & Structured Data for WP & AMP` 用に作成し、本文FAQと質問文・回答内容を一致させる。JSON-LDだけあり本文FAQが無い、または本文FAQがqa-boxでない場合はFAIL。
- FAQには、旧記事、301、公開QA、Hub、heartbeat、cron、Gate、PASS/FAILなど内部作業設問を入れない。
- 装飾は太字、黄色アンダー、赤太字、✅、⚠️、Cocoon系ボックス、リストをバランスよく使い分ける。
- `<li>` の先頭へ毎回✅/⚠️を付けない。リスト記号とアイコンの二重信号で読みづらい場合はFAIL。
- `information-box` / `warning-box` / `blank-box` などボックス自体が意味を持つ場合、原則として✅/⚠️を重ねない。必要な場合だけ最小限にする。
- ✅/⚠️だけを使う箇所、リストを使う箇所、ボックスを使う箇所を分ける。装飾不足も過剰装飾もFAIL。
- 既知の検出必須例: https://porn-fun.com/sites/fc2-live-adult-review/ は、評価項目本文見出し不足、qa-box FAQ不足、装飾バランス不備として訂正対象。

全評価ページ共通 / ✅・⚠️優先装飾Gate（2026-05-17追加）:
- 強み・注意点・向いている人・向いていない人を短く見せられる箇所では、ただの箇条書きより✅/⚠️の単独強調文を優先する。
- ✅は強み/向いている人/判断しやすい利点、⚠️は注意点/向いていない人/確認が必要な条件/制約に使う。
- 1文で伝わる強み/注意点は `<p>✅ ...</p>` / `<p>⚠️ ...</p>` のような単独文を優先する。
- 複数条件を並列整理するときは`<ul><li>`を使ってよいが、各`li`先頭へ毎回✅/⚠️を付けない。
- `information-box` / `warning-box` / `blank-box`などボックス自体が意味を持つ場合、ボックス内へ✅/⚠️を機械的に重ねない。
- 評価ページで✅/⚠️が0件のまま、強みや注意点をすべて普通の`li`やボックスだけで処理している場合は装飾不足としてFAIL。
- 既知の検出必須例: https://porn-fun.com/sites/fc2-live-adult-review/ は、qa-boxは改善済みだが✅/⚠️が0件のため訂正対象。

全サイト共通 / 1-C〜7制作完了→8高品質テスト引き渡しGate（2026-05-17追加）:
- 1-C〜7で記事を公開したら、公開URLを作っただけで終わらず、同じarticle_keyで task_code=8 / use_status=public_qa_handoff / check_status=ready / status=active のReferencesを必ず作る。
- 8高品質テストは、public_qa_handoffだけでなく、use_status=published_directory_article / task_code=7 / 公開済み新記事URLも横断して確認する。
- 同じarticle_keyにtask8 PASSまたはtask8 high-quality test完了記録が無い公開済み記事を「未処理対象なし」と扱わない。
- 7の公開HTML QA PASS、Directory Core入力PASS、published_directory_articleがあるのに8のPASSが無い場合は、明示ハンドオフ漏れとして8対象にする。
- Hub認証不備時は対象なし/PASS/完了と誤判定せず、BLOCKED_HUB_AUTHとして終了する。
- 既知の補正例: https://porn-fun.com/sites/hey-douga-review/ は1-C〜7で公開済みだが、8用の明示的ハンドオフが弱かったため、public_qa_handoffを追加して8対象に戻した。

cron標準 / サイト別1スレッド運用（2026-05-17追加）:
- オートポスト支社の通常運用はcron標準。heartbeatは例外運用に限る。
- 1サイトまたは1セットにつき、関連cronを依頼・管理する起動スレッドは1つだけにする。
- 各タスクごとの新スレッド立ち上げ文は不要。各タスク欄のコピー文は、そのサイト別cron統括スレッド内で使うcron作成依頼文として扱う。
- automation名は `【サイト名＋評価スコアページ種別】タスク順番 cron 内容` を標準にする。
- 1回1記事制限、最大処理件数、対象なし終了、BLOCKED_*終了条件はcron本文内に書く。
- Hub正本、Work Queue、References、FactChecks、台帳で状態管理する。
- heartbeatは、ユーザーと同じスレッドで短時間だけ追跡する場合、手動確認が必要な一時作業、緊急修正、外部AI/改善担当との会話型ハンドオフが必要な場合だけ使う。

cron個別作成Gate:
- サイト別cron統括スレッド起動文を貼っただけではcronを作成しない。
- 統括スレッド起動文では、Hub、agent_pack、Work Queue、References、FactChecks、台帳、既存automationを確認し、既存cronと未作成cronを整理して報告するだけにする。
- cron作成は、ユーザーが各タスク欄のcron作成依頼文を個別に貼った時だけ行う。
- 1回のcron作成依頼文で作るautomationは1つだけにする。
- ユーザーが「全cronをまとめて作って」と明示しない限り、複数cronを一括作成しない。

評価スコアページ用cron命名Gate:
このcronは、まとめページ、キラーページ、通常記事、速報記事ではなく、評価スコア表を持つ辞書型・レビュー型ページ専用として扱う。
automation名には必ず「評価スコアページ」を入れる。
例:
- 【AIfunIO評価スコアページ】0-A cron 候補収集
- 【Nightlife夜遊び店舗評価スコアページ】0-B/1-A/1-B cron 候補精査・参照URL整理・URL検証
- 【Nightlifeホテル評価スコアページ】8 cron 高品質テスト
- 【porn-fun単体サービス評価スコアページ移行】11 cron 301実行・リダイレクト確認
まとめ/ランキング/比較/通常/速報記事用のautomationは別命名・別テンプレートにする。

Nightlife夜遊び店舗用 収集cron automation作成依頼文

コピー

Nightlife夜遊び店舗用 収集cron automationを作成してください。

automation名: 【Nightlife夜遊び店舗評価スコアページ】0-A cron 候補収集
名前は必ずこの形で登録してください。人間がautomation一覧を見た時に、サイト名・タスク順番・cron/heartbeat・内容が分かるようにします。

対象: Nightlife / 夜遊び店舗 / nightlife-directory-review-ja
区分: cron
起動時間: JST 02:10
頻度: 1日1回 / 1回最大10件

目的:
夜遊び店舗候補の0-A在庫を補充する。

共通ルール:
- Main Hubを正本にする。Standby Hubはreadonly、Googleスプレッドシート/Apps Script/Google承認には戻らない。
- ローカルPC内の storage/data/358-hub.sqlite が無いだけで止まらない。Main Hub Web、agent_pack、Work Queue、References、FactChecks、hub_table_upsert相当の利用可能手段を優先する。
- 認証情報、APIキー、パスワード、トークン、WordPress REST認証情報の中身は表示しない。
- 通常の.mdログ、記事本文、キュー、投稿結果の更新ではapply_patchを使わない。承認が出にくい安全な書き込み手段を使う。
- PHP/JS/CSS等の本番コード編集、ファイル削除、移動、上書き、外部公開先の新規追加、認証情報、権限変更は停止して確認する。
- 公開投稿そのものは停止条件ではない。止めるのは未承認、未検査、危険操作、GATE失敗の場合だけ。
- 0-A/0-Bなどの棚処理は複数候補を扱ってよい。1回1記事制限は制作cron、高品質テストcron、訂正cron、改善担当ハンドオフcronに適用する。
- automation名は `【サイト名＋評価スコアページ種別】タスク順番 cron 内容` の形で登録する。
- 各cronを作る時は、対象レポート記事の各項目にある新スレ起動文を先に貼り、専用スレッドとして状態復元してからautomationを作成する。
- Main Hubが401/403/invalid token/token expired/timeout/DNS/network error等で読めない場合、その回は対象なし、FAILなし、PASS、完了と判断しない。必ず `BLOCKED_HUB_AUTH / Hub認証不備 / 正本未確認 / 記事修正なし` と報告する。
- Hub正本を読めない状態で、公開、修正、301、Hub更新、PASS/FAIL確定を行わない。

全記事共通Gate:
- 全評価ページ共通で、冒頭はH1タイトル → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2の順にする。
- 公式テキストリンクは、アフィリエイトリンクがある場合はアフィリエイトリンク、無い場合は公式リンクにする。
- 公式テキストリンクはPC表示で本文右側または右寄せに置く。読者が本文導線として見つけられる位置にする。
- 参照例は https://invest358.com/ja/thinkmarkets-review/ とする。完全コピーではなく、冒頭構成と導線を継承する。
- H1重複、H1へのSEOタイトル混入、評価表の順序崩れ、公式リンク漏れ、コード露出、言語不一致はFAIL。
- 日本語ページは常体を基本にする。ただし偉そうにせず、落ち着いた説明文にする。対象ページの言語に合わせて基本表/補足情報も同じ言語で書く。
- 装飾は既存良質記事を継承する。太字、太字+黄色アンダー、赤太字、✅、⚠️、Cocoon系ボックスを必要箇所へ自然に入れる。
- 9-Aで文章QA/共起語改善候補を抽出し、9-Bで改善担当へ渡し、10で返却反映と硬いGate確認を行う。
- improvement_status、improvement_owner、improvement_lockを記録する。handed_offかつlock中の本文を返却前に主観リライトしない。

サイト別Gate:
- Nightlife夜遊び店舗は、H1は店舗/サービス名のみ。SEOタイトルは「店舗名 + 評価・評判・レビュー」系KWを含める。
- 最寄り駅、営業時間、料金目安、予約/問い合わせ、決済方法、対応エリアは公式または補助根拠を調べて書く。
- 公式で要確認などの空欄逃げを本文/表/Directory Core値に残したらFAIL。断定できない場合は根拠と不確実性を整理する。

やること:
- 候補をmemoryだけで終えず、Main Hubの棚/Work Queue/References/FactChecksへ次工程が読める形で残す。
- 既存上限を超える場合は新規収集より整理を優先する。

止める条件:
- GATE失敗、未承認サイト、認証情報、権限変更、ファイル削除/移動/上書き、本番コード編集、外部公開先の新規追加。
- 公開投稿そのものは停止条件にしない。

出力:
候補数、採用候補、保留候補、Hub登録結果を報告する。

全評価ページ共通 / task10・8・9-A/9-B 訂正対象取得Gate（2026-05-17追記）:
- `task10/FAILキュー` という名前だけを見て0件判定しない。
- Main HubのWork Queue / Tasks、References、FactChecks、9-A/9-Bのreturned状態を横断して確認する。
- Referencesの `use_status=correction_queue`、`public_qa_handoff`、`quality_fail`、`correction_required`、または `check_status=ready/fail/failed` を訂正対象として見る。
- FactChecksの `fact_check_id`、`check_status`、`notes` に `fail` / `FAIL` / `Gate failed` / `Gate失敗` / `要修正` があるものを拾う。
- workflow共通の `article_key` だけに限定せず、記事別key、slug別key、移行記事keyも同じsite/workflow/domain内なら拾う。
- agent_packに他サイトのFAILが混在して見える場合は、対象site / workflow / domain / article_typeで絞り込み、別サイトのFAILを自分の訂正対象にしない。
- 上記を確認せずに「FAILキュー0件」「対象なし」「記事修正なし」「301対応なし」「PASS/完了」と報告しない。
- Hubが401/403/invalid token/token expired/timeout/DNS/network errorで読めない場合は、対象なし扱いにせず `BLOCKED_HUB_AUTH / Hub認証不備 / 正本未確認 / 記事修正なし` と報告する。

全評価ページ共通 / 公開本文境界Gate（2026-05-17追記）:
- 公開本文には、読者のサービス判断に必要な情報だけを書く。
- 301、リダイレクト、旧URL、旧記事、新辞書記事、移行、公開QA、Gate、PASS、FAIL、Hub、Work Queue、References、FactChecks、agent_pack、heartbeat、cron、automation、タスク番号、制作パック、台帳、作業ログを本文に書かない。
- 「この制作cronでは301を実行しない」「別工程で旧URLからの301を扱う」「辞書記事では整理する」など、作業工程の説明を本文に出さない。
- これらは内部ログ、Hub、台帳、QA記録にだけ残す。
- 公開本文では、サービス内容、料金、無料範囲、年齢制限、登録、決済、退会、安全面、注意点、公式リンクなど読者向け情報へ書き換える。
- 本文・見出し・表・FAQ・CTA周辺に内部運用語があればFAILとし、公開継続または301実行前に修正する。

全評価ページ共通 / 検索意図・上位傾向・共起語整理Gate（2026-05-17追記）:
- 公式情報と参照URL検証が終わった後、1-C記事制作パック前に `1-B2 検索意図・上位傾向・共起語整理` を行う。
- 整理するものは、読者の主要検索意図、上位記事でよく扱われる論点、自然に使えそうな共起語、使わない語、H2/H3・評価表・FAQ・リード文への反映案。
- 共起語は本文へ機械的に詰め込むノルマではない。読者理解を助ける範囲で自然に使う。
- 公式情報と矛盾する上位傾向、サービス内容と関係が薄い語、根拠不足の語は採用しない。
- 1-C制作パックには「自然使用候補」「使わない語」「構成への反映案」を分けて残す。
- 8高品質テストと9-A改善候補抽出では、このメモを見て「不足」「過剰」「不自然な詰め込み」「無関係語の混入」を確認する。

Task10本文修正・終了状態Gate（2026-05-17追加）:
- FAIL原因が本文、FAQ、冒頭構成にある場合、第一手はWordPress本文修正にする。
- Cocoon設定、page_type、テーマ設定、広告/PR表示設定などの設定側変更は補助手段。H1重複、表示崩れ、評価表欠落、本文順序崩れのリスクが出た時点で撤回し、本文修正ルートへ戻る。
- 設定側を触って失敗しただけで本文修正せずに終了しない。
- 内部作業文を公開本文から削除する。
- FAQ内の内部作業設問を削除し、必要なら読者向けFAQへ置き換える。例: 「旧記事から301してよいか」「この制作cronでは301を実行しない」「公開QAが通ったあと」は削除対象。
- 冒頭順を H1 → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2 に整える。
- 公開HTMLでH1重複、コード露出、内部作業語、評価表、公式リンク、canonical、noindexを再確認する。
- PASS後にだけ301可否へ進む。PASS前に旧URLから301しない。
- 1回のcronでは1記事だけ処理する。同じ失敗ルートを繰り返さない。
- 作業は必ず PASS / FAIL_REQUEUED / BLOCKED_HUB_AUTH / BLOCKED_WP_AUTH / BLOCKED_WP_WRITE / BLOCKED_LAYOUT_RISK / BLOCKED_MISSING_TARGET のいずれかで終了する。ローディングし続けない。

評価項目本文化・FAQ qa-box・装飾バランスGate（2026-05-17追加）:
- 評価スコア表の各項目は、本文内でH2またはH3見出しとして扱い、スコア理由、読者が確認すべき点、向いている人/注意点を書く。表だけで終わらせない。
- 評価項目名と本文見出し名は、完全一致または読者が同じ項目だと分かる名前にする。評価項目の説明が無い場合は本文ボリューム不足としてFAIL。
- 本文FAQは `<details class="qa-box"><summary>質問文</summary><div class="qa-answer">回答文</div></details>` を標準にする。
- FAQPage JSON-LDは `Schema & Structured Data for WP & AMP` 用に作成し、本文FAQと質問文・回答内容を一致させる。JSON-LDだけあり本文FAQが無い、または本文FAQがqa-boxでない場合はFAIL。
- FAQには、旧記事、301、公開QA、Hub、heartbeat、cron、Gate、PASS/FAILなど内部作業設問を入れない。
- 装飾は太字、黄色アンダー、赤太字、✅、⚠️、Cocoon系ボックス、リストをバランスよく使い分ける。
- `<li>` の先頭へ毎回✅/⚠️を付けない。リスト記号とアイコンの二重信号で読みづらい場合はFAIL。
- `information-box` / `warning-box` / `blank-box` などボックス自体が意味を持つ場合、原則として✅/⚠️を重ねない。必要な場合だけ最小限にする。
- ✅/⚠️だけを使う箇所、リストを使う箇所、ボックスを使う箇所を分ける。装飾不足も過剰装飾もFAIL。
- 既知の検出必須例: https://porn-fun.com/sites/fc2-live-adult-review/ は、評価項目本文見出し不足、qa-box FAQ不足、装飾バランス不備として訂正対象。

全評価ページ共通 / ✅・⚠️優先装飾Gate（2026-05-17追加）:
- 強み・注意点・向いている人・向いていない人を短く見せられる箇所では、ただの箇条書きより✅/⚠️の単独強調文を優先する。
- ✅は強み/向いている人/判断しやすい利点、⚠️は注意点/向いていない人/確認が必要な条件/制約に使う。
- 1文で伝わる強み/注意点は `<p>✅ ...</p>` / `<p>⚠️ ...</p>` のような単独文を優先する。
- 複数条件を並列整理するときは`<ul><li>`を使ってよいが、各`li`先頭へ毎回✅/⚠️を付けない。
- `information-box` / `warning-box` / `blank-box`などボックス自体が意味を持つ場合、ボックス内へ✅/⚠️を機械的に重ねない。
- 評価ページで✅/⚠️が0件のまま、強みや注意点をすべて普通の`li`やボックスだけで処理している場合は装飾不足としてFAIL。
- 既知の検出必須例: https://porn-fun.com/sites/fc2-live-adult-review/ は、qa-boxは改善済みだが✅/⚠️が0件のため訂正対象。

全サイト共通 / 1-C〜7制作完了→8高品質テスト引き渡しGate（2026-05-17追加）:
- 1-C〜7で記事を公開したら、公開URLを作っただけで終わらず、同じarticle_keyで task_code=8 / use_status=public_qa_handoff / check_status=ready / status=active のReferencesを必ず作る。
- 8高品質テストは、public_qa_handoffだけでなく、use_status=published_directory_article / task_code=7 / 公開済み新記事URLも横断して確認する。
- 同じarticle_keyにtask8 PASSまたはtask8 high-quality test完了記録が無い公開済み記事を「未処理対象なし」と扱わない。
- 7の公開HTML QA PASS、Directory Core入力PASS、published_directory_articleがあるのに8のPASSが無い場合は、明示ハンドオフ漏れとして8対象にする。
- Hub認証不備時は対象なし/PASS/完了と誤判定せず、BLOCKED_HUB_AUTHとして終了する。
- 既知の補正例: https://porn-fun.com/sites/hey-douga-review/ は1-C〜7で公開済みだが、8用の明示的ハンドオフが弱かったため、public_qa_handoffを追加して8対象に戻した。

cron標準 / サイト別1スレッド運用（2026-05-17追加）:
- オートポスト支社の通常運用はcron標準。heartbeatは例外運用に限る。
- 1サイトまたは1セットにつき、関連cronを依頼・管理する起動スレッドは1つだけにする。
- 各タスクごとの新スレッド立ち上げ文は不要。各タスク欄のコピー文は、そのサイト別cron統括スレッド内で使うcron作成依頼文として扱う。
- automation名は `【サイト名＋評価スコアページ種別】タスク順番 cron 内容` を標準にする。
- 1回1記事制限、最大処理件数、対象なし終了、BLOCKED_*終了条件はcron本文内に書く。
- Hub正本、Work Queue、References、FactChecks、台帳で状態管理する。
- heartbeatは、ユーザーと同じスレッドで短時間だけ追跡する場合、手動確認が必要な一時作業、緊急修正、外部AI/改善担当との会話型ハンドオフが必要な場合だけ使う。

cron個別作成Gate:
- サイト別cron統括スレッド起動文を貼っただけではcronを作成しない。
- 統括スレッド起動文では、Hub、agent_pack、Work Queue、References、FactChecks、台帳、既存automationを確認し、既存cronと未作成cronを整理して報告するだけにする。
- cron作成は、ユーザーが各タスク欄のcron作成依頼文を個別に貼った時だけ行う。
- 1回のcron作成依頼文で作るautomationは1つだけにする。
- ユーザーが「全cronをまとめて作って」と明示しない限り、複数cronを一括作成しない。

評価スコアページ用cron命名Gate:
このcronは、まとめページ、キラーページ、通常記事、速報記事ではなく、評価スコア表を持つ辞書型・レビュー型ページ専用として扱う。
automation名には必ず「評価スコアページ」を入れる。
例:
- 【AIfunIO評価スコアページ】0-A cron 候補収集
- 【Nightlife夜遊び店舗評価スコアページ】0-B/1-A/1-B cron 候補精査・参照URL整理・URL検証
- 【Nightlifeホテル評価スコアページ】8 cron 高品質テスト
- 【porn-fun単体サービス評価スコアページ移行】11 cron 301実行・リダイレクト確認
まとめ/ランキング/比較/通常/速報記事用のautomationは別命名・別テンプレートにする。

Nightlife夜遊び店舗用 検査cron

automation名: 【Nightlife夜遊び店舗評価スコアページ】0-B/1-A/1-B cron 候補精査・参照URL整理・URL検証

Nightlife夜遊び店舗用 検査cron 新スレ起動文

コピー

# 【Nightlife夜遊び店舗評価スコアページ】0-B/1-A/1-B cron 候補精査・参照URL整理・URL検証 新スレ起動文

このスレッドは、以下のautomationだけを作成・運用する専用スレッドです。
1スレッドにheartbeatは1つだけなので、他のcron用途を混ぜないでください。
cron automationの場合も、このサイト別cron統括スレッド内で、このcron作成依頼として扱ってください。

作成するautomation名:
【Nightlife夜遊び店舗評価スコアページ】0-B/1-A/1-B cron 候補精査・参照URL整理・URL検証

対象:
Nightlife / 夜遊び店舗 / nightlife-directory-review-ja

区分:
cron

起動時間:
JST 00:40 / 06:40 / 14:40 / 18:40

頻度:
1日4回 / 1回最大6件

目的:
0-B候補精査、1-A参照URL整理、1-B URL検証を進める。

最初に確認するもの:
- Main Hub: https://hub.goudou-358.jp
- 対象レポート: https://report.goudou-358.jp/nightlife-store-automation-request-templates-20260517/
- CODE-YUKI作業室: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI
- CODE-YUKI引継ぎ控え: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI\handoffs\2026-05-17_global_opening_gate_external_hb_handoff.md
- 外部HB起動文控え: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI\handoffs\2026-05-17_external_improvement_hb_startup_prompt.md
- オートポスト支社共有: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common
- branch_common保険控え: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common\manuals\first-development-source-copies\2026-05-17-global-opening-improvement-gate\global-opening-improvement-handoff.md
- Nightlife正本: Main Hub / workflow_id=nightlife-directory-review-ja
- Nightlife共通台帳: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common\ledgers\directory-core\directory-article-input-ledger.md
- Nightlife辞書セット共通台帳: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common\ledgers\directory-core\directory-set-template-registry.md
- Nightlifeローカル保険控え: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common\manuals\first-development-source-copies
- Nightlife専用サイト部フォルダが未分離の場合は、Main Hub正本とCODE-YUKI作業室を優先する。

必ず守ること:
- automation作成時の名前は、上記のautomation名をそのまま使う。
- Main Hubを正本にし、agent_pack / Work Queue / References / FactChecks / Rules / Manualsを確認してから動く。
- ローカルPC内の storage/data/358-hub.sqlite が無いだけで停止しない。
- 認証情報、APIキー、パスワード、トークン、WordPress REST認証情報の中身を読まない・表示しない。
- 通常の.mdログ、記事本文、キュー、投稿結果の更新ではapply_patchを使わない。
- GATE失敗、未承認、危険操作、認証情報、権限変更、ファイル削除/移動/上書き、本番コード編集は停止して確認する。
- Hubが401/403/invalid token等で読めない場合は、対象なし扱いにしない。`BLOCKED_HUB_AUTH / Hub認証不備 / 正本未確認 / 記事修正なし` と報告する。

全記事共通Gate:
- 冒頭構成は H1タイトル → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2。
- 公式テキストリンクは、アフィリエイトリンクがある場合はアフィリエイトリンク、無い場合は公式リンク。
- 公式テキストリンクはPC表示で本文右側または右寄せ。
- 参照例: https://invest358.com/ja/thinkmarkets-review/
- H1重複、コード露出、公式で要確認などの仮置き、言語不一致、装飾不足はFAIL。

この内容でautomationを作成してください。
作成後は、automation名、区分、起動時間、対象、初回実行で確認するHub項目を報告してください。

全評価ページ共通 / task10・8・9-A/9-B 訂正対象取得Gate（2026-05-17追記）:
- `task10/FAILキュー` という名前だけを見て0件判定しない。
- Main HubのWork Queue / Tasks、References、FactChecks、9-A/9-Bのreturned状態を横断して確認する。
- Referencesの `use_status=correction_queue`、`public_qa_handoff`、`quality_fail`、`correction_required`、または `check_status=ready/fail/failed` を訂正対象として見る。
- FactChecksの `fact_check_id`、`check_status`、`notes` に `fail` / `FAIL` / `Gate failed` / `Gate失敗` / `要修正` があるものを拾う。
- workflow共通の `article_key` だけに限定せず、記事別key、slug別key、移行記事keyも同じsite/workflow/domain内なら拾う。
- agent_packに他サイトのFAILが混在して見える場合は、対象site / workflow / domain / article_typeで絞り込み、別サイトのFAILを自分の訂正対象にしない。
- 上記を確認せずに「FAILキュー0件」「対象なし」「記事修正なし」「301対応なし」「PASS/完了」と報告しない。
- Hubが401/403/invalid token/token expired/timeout/DNS/network errorで読めない場合は、対象なし扱いにせず `BLOCKED_HUB_AUTH / Hub認証不備 / 正本未確認 / 記事修正なし` と報告する。

全評価ページ共通 / 公開本文境界Gate（2026-05-17追記）:
- 公開本文には、読者のサービス判断に必要な情報だけを書く。
- 301、リダイレクト、旧URL、旧記事、新辞書記事、移行、公開QA、Gate、PASS、FAIL、Hub、Work Queue、References、FactChecks、agent_pack、heartbeat、cron、automation、タスク番号、制作パック、台帳、作業ログを本文に書かない。
- 「この制作cronでは301を実行しない」「別工程で旧URLからの301を扱う」「辞書記事では整理する」など、作業工程の説明を本文に出さない。
- これらは内部ログ、Hub、台帳、QA記録にだけ残す。
- 公開本文では、サービス内容、料金、無料範囲、年齢制限、登録、決済、退会、安全面、注意点、公式リンクなど読者向け情報へ書き換える。
- 本文・見出し・表・FAQ・CTA周辺に内部運用語があればFAILとし、公開継続または301実行前に修正する。

全評価ページ共通 / 検索意図・上位傾向・共起語整理Gate（2026-05-17追記）:
- 公式情報と参照URL検証が終わった後、1-C記事制作パック前に `1-B2 検索意図・上位傾向・共起語整理` を行う。
- 整理するものは、読者の主要検索意図、上位記事でよく扱われる論点、自然に使えそうな共起語、使わない語、H2/H3・評価表・FAQ・リード文への反映案。
- 共起語は本文へ機械的に詰め込むノルマではない。読者理解を助ける範囲で自然に使う。
- 公式情報と矛盾する上位傾向、サービス内容と関係が薄い語、根拠不足の語は採用しない。
- 1-C制作パックには「自然使用候補」「使わない語」「構成への反映案」を分けて残す。
- 8高品質テストと9-A改善候補抽出では、このメモを見て「不足」「過剰」「不自然な詰め込み」「無関係語の混入」を確認する。

Task10本文修正・終了状態Gate（2026-05-17追加）:
- FAIL原因が本文、FAQ、冒頭構成にある場合、第一手はWordPress本文修正にする。
- Cocoon設定、page_type、テーマ設定、広告/PR表示設定などの設定側変更は補助手段。H1重複、表示崩れ、評価表欠落、本文順序崩れのリスクが出た時点で撤回し、本文修正ルートへ戻る。
- 設定側を触って失敗しただけで本文修正せずに終了しない。
- 内部作業文を公開本文から削除する。
- FAQ内の内部作業設問を削除し、必要なら読者向けFAQへ置き換える。例: 「旧記事から301してよいか」「この制作cronでは301を実行しない」「公開QAが通ったあと」は削除対象。
- 冒頭順を H1 → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2 に整える。
- 公開HTMLでH1重複、コード露出、内部作業語、評価表、公式リンク、canonical、noindexを再確認する。
- PASS後にだけ301可否へ進む。PASS前に旧URLから301しない。
- 1回のcronでは1記事だけ処理する。同じ失敗ルートを繰り返さない。
- 作業は必ず PASS / FAIL_REQUEUED / BLOCKED_HUB_AUTH / BLOCKED_WP_AUTH / BLOCKED_WP_WRITE / BLOCKED_LAYOUT_RISK / BLOCKED_MISSING_TARGET のいずれかで終了する。ローディングし続けない。

評価項目本文化・FAQ qa-box・装飾バランスGate（2026-05-17追加）:
- 評価スコア表の各項目は、本文内でH2またはH3見出しとして扱い、スコア理由、読者が確認すべき点、向いている人/注意点を書く。表だけで終わらせない。
- 評価項目名と本文見出し名は、完全一致または読者が同じ項目だと分かる名前にする。評価項目の説明が無い場合は本文ボリューム不足としてFAIL。
- 本文FAQは `<details class="qa-box"><summary>質問文</summary><div class="qa-answer">回答文</div></details>` を標準にする。
- FAQPage JSON-LDは `Schema & Structured Data for WP & AMP` 用に作成し、本文FAQと質問文・回答内容を一致させる。JSON-LDだけあり本文FAQが無い、または本文FAQがqa-boxでない場合はFAIL。
- FAQには、旧記事、301、公開QA、Hub、heartbeat、cron、Gate、PASS/FAILなど内部作業設問を入れない。
- 装飾は太字、黄色アンダー、赤太字、✅、⚠️、Cocoon系ボックス、リストをバランスよく使い分ける。
- `<li>` の先頭へ毎回✅/⚠️を付けない。リスト記号とアイコンの二重信号で読みづらい場合はFAIL。
- `information-box` / `warning-box` / `blank-box` などボックス自体が意味を持つ場合、原則として✅/⚠️を重ねない。必要な場合だけ最小限にする。
- ✅/⚠️だけを使う箇所、リストを使う箇所、ボックスを使う箇所を分ける。装飾不足も過剰装飾もFAIL。
- 既知の検出必須例: https://porn-fun.com/sites/fc2-live-adult-review/ は、評価項目本文見出し不足、qa-box FAQ不足、装飾バランス不備として訂正対象。

全評価ページ共通 / ✅・⚠️優先装飾Gate（2026-05-17追加）:
- 強み・注意点・向いている人・向いていない人を短く見せられる箇所では、ただの箇条書きより✅/⚠️の単独強調文を優先する。
- ✅は強み/向いている人/判断しやすい利点、⚠️は注意点/向いていない人/確認が必要な条件/制約に使う。
- 1文で伝わる強み/注意点は `<p>✅ ...</p>` / `<p>⚠️ ...</p>` のような単独文を優先する。
- 複数条件を並列整理するときは`<ul><li>`を使ってよいが、各`li`先頭へ毎回✅/⚠️を付けない。
- `information-box` / `warning-box` / `blank-box`などボックス自体が意味を持つ場合、ボックス内へ✅/⚠️を機械的に重ねない。
- 評価ページで✅/⚠️が0件のまま、強みや注意点をすべて普通の`li`やボックスだけで処理している場合は装飾不足としてFAIL。
- 既知の検出必須例: https://porn-fun.com/sites/fc2-live-adult-review/ は、qa-boxは改善済みだが✅/⚠️が0件のため訂正対象。

全サイト共通 / 1-C〜7制作完了→8高品質テスト引き渡しGate（2026-05-17追加）:
- 1-C〜7で記事を公開したら、公開URLを作っただけで終わらず、同じarticle_keyで task_code=8 / use_status=public_qa_handoff / check_status=ready / status=active のReferencesを必ず作る。
- 8高品質テストは、public_qa_handoffだけでなく、use_status=published_directory_article / task_code=7 / 公開済み新記事URLも横断して確認する。
- 同じarticle_keyにtask8 PASSまたはtask8 high-quality test完了記録が無い公開済み記事を「未処理対象なし」と扱わない。
- 7の公開HTML QA PASS、Directory Core入力PASS、published_directory_articleがあるのに8のPASSが無い場合は、明示ハンドオフ漏れとして8対象にする。
- Hub認証不備時は対象なし/PASS/完了と誤判定せず、BLOCKED_HUB_AUTHとして終了する。
- 既知の補正例: https://porn-fun.com/sites/hey-douga-review/ は1-C〜7で公開済みだが、8用の明示的ハンドオフが弱かったため、public_qa_handoffを追加して8対象に戻した。

cron標準 / サイト別1スレッド運用（2026-05-17追加）:
- オートポスト支社の通常運用はcron標準。heartbeatは例外運用に限る。
- 1サイトまたは1セットにつき、関連cronを依頼・管理する起動スレッドは1つだけにする。
- 各タスクごとの新スレッド立ち上げ文は不要。各タスク欄のコピー文は、そのサイト別cron統括スレッド内で使うcron作成依頼文として扱う。
- automation名は `【サイト名＋評価スコアページ種別】タスク順番 cron 内容` を標準にする。
- 1回1記事制限、最大処理件数、対象なし終了、BLOCKED_*終了条件はcron本文内に書く。
- Hub正本、Work Queue、References、FactChecks、台帳で状態管理する。
- heartbeatは、ユーザーと同じスレッドで短時間だけ追跡する場合、手動確認が必要な一時作業、緊急修正、外部AI/改善担当との会話型ハンドオフが必要な場合だけ使う。

cron個別作成Gate:
- サイト別cron統括スレッド起動文を貼っただけではcronを作成しない。
- 統括スレッド起動文では、Hub、agent_pack、Work Queue、References、FactChecks、台帳、既存automationを確認し、既存cronと未作成cronを整理して報告するだけにする。
- cron作成は、ユーザーが各タスク欄のcron作成依頼文を個別に貼った時だけ行う。
- 1回のcron作成依頼文で作るautomationは1つだけにする。
- ユーザーが「全cronをまとめて作って」と明示しない限り、複数cronを一括作成しない。

評価スコアページ用cron命名Gate:
このcronは、まとめページ、キラーページ、通常記事、速報記事ではなく、評価スコア表を持つ辞書型・レビュー型ページ専用として扱う。
automation名には必ず「評価スコアページ」を入れる。
例:
- 【AIfunIO評価スコアページ】0-A cron 候補収集
- 【Nightlife夜遊び店舗評価スコアページ】0-B/1-A/1-B cron 候補精査・参照URL整理・URL検証
- 【Nightlifeホテル評価スコアページ】8 cron 高品質テスト
- 【porn-fun単体サービス評価スコアページ移行】11 cron 301実行・リダイレクト確認
まとめ/ランキング/比較/通常/速報記事用のautomationは別命名・別テンプレートにする。

Nightlife夜遊び店舗用 検査cron automation作成依頼文

コピー

Nightlife夜遊び店舗用 検査cron automationを作成してください。

automation名: 【Nightlife夜遊び店舗評価スコアページ】0-B/1-A/1-B cron 候補精査・参照URL整理・URL検証
名前は必ずこの形で登録してください。人間がautomation一覧を見た時に、サイト名・タスク順番・cron/heartbeat・内容が分かるようにします。

対象: Nightlife / 夜遊び店舗 / nightlife-directory-review-ja
区分: cron
起動時間: JST 00:40 / 06:40 / 14:40 / 18:40
頻度: 1日4回 / 1回最大6件

目的:
0-B候補精査、1-A参照URL整理、1-B URL検証を進める。

共通ルール:
- Main Hubを正本にする。Standby Hubはreadonly、Googleスプレッドシート/Apps Script/Google承認には戻らない。
- ローカルPC内の storage/data/358-hub.sqlite が無いだけで止まらない。Main Hub Web、agent_pack、Work Queue、References、FactChecks、hub_table_upsert相当の利用可能手段を優先する。
- 認証情報、APIキー、パスワード、トークン、WordPress REST認証情報の中身は表示しない。
- 通常の.mdログ、記事本文、キュー、投稿結果の更新ではapply_patchを使わない。承認が出にくい安全な書き込み手段を使う。
- PHP/JS/CSS等の本番コード編集、ファイル削除、移動、上書き、外部公開先の新規追加、認証情報、権限変更は停止して確認する。
- 公開投稿そのものは停止条件ではない。止めるのは未承認、未検査、危険操作、GATE失敗の場合だけ。
- 0-A/0-Bなどの棚処理は複数候補を扱ってよい。1回1記事制限は制作cron、高品質テストcron、訂正cron、改善担当ハンドオフcronに適用する。
- automation名は `【サイト名＋評価スコアページ種別】タスク順番 cron 内容` の形で登録する。
- 各cronを作る時は、対象レポート記事の各項目にある新スレ起動文を先に貼り、専用スレッドとして状態復元してからautomationを作成する。
- Main Hubが401/403/invalid token/token expired/timeout/DNS/network error等で読めない場合、その回は対象なし、FAILなし、PASS、完了と判断しない。必ず `BLOCKED_HUB_AUTH / Hub認証不備 / 正本未確認 / 記事修正なし` と報告する。
- Hub正本を読めない状態で、公開、修正、301、Hub更新、PASS/FAIL確定を行わない。

全記事共通Gate:
- 全評価ページ共通で、冒頭はH1タイトル → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2の順にする。
- 公式テキストリンクは、アフィリエイトリンクがある場合はアフィリエイトリンク、無い場合は公式リンクにする。
- 公式テキストリンクはPC表示で本文右側または右寄せに置く。読者が本文導線として見つけられる位置にする。
- 参照例は https://invest358.com/ja/thinkmarkets-review/ とする。完全コピーではなく、冒頭構成と導線を継承する。
- H1重複、H1へのSEOタイトル混入、評価表の順序崩れ、公式リンク漏れ、コード露出、言語不一致はFAIL。
- 日本語ページは常体を基本にする。ただし偉そうにせず、落ち着いた説明文にする。対象ページの言語に合わせて基本表/補足情報も同じ言語で書く。
- 装飾は既存良質記事を継承する。太字、太字+黄色アンダー、赤太字、✅、⚠️、Cocoon系ボックスを必要箇所へ自然に入れる。
- 9-Aで文章QA/共起語改善候補を抽出し、9-Bで改善担当へ渡し、10で返却反映と硬いGate確認を行う。
- improvement_status、improvement_owner、improvement_lockを記録する。handed_offかつlock中の本文を返却前に主観リライトしない。

サイト別Gate:
- Nightlife夜遊び店舗は、H1は店舗/サービス名のみ。SEOタイトルは「店舗名 + 評価・評判・レビュー」系KWを含める。
- 最寄り駅、営業時間、料金目安、予約/問い合わせ、決済方法、対応エリアは公式または補助根拠を調べて書く。
- 公式で要確認などの空欄逃げを本文/表/Directory Core値に残したらFAIL。断定できない場合は根拠と不確実性を整理する。

やること:
- 候補ごとに公式/補助URLを整理し、0-B/1-A/1-Bの判定をMain Hubへ残す。
- 制作readyに渡せる候補を複数件作る。ただし根拠不足や仮置きのまま制作へ進めない。

止める条件:
- GATE失敗、未承認サイト、認証情報、権限変更、ファイル削除/移動/上書き、本番コード編集、外部公開先の新規追加。
- 公開投稿そのものは停止条件にしない。

出力:
PASS/FAIL/保留、制作ready件数、根拠URL不足を報告する。

全評価ページ共通 / task10・8・9-A/9-B 訂正対象取得Gate（2026-05-17追記）:
- `task10/FAILキュー` という名前だけを見て0件判定しない。
- Main HubのWork Queue / Tasks、References、FactChecks、9-A/9-Bのreturned状態を横断して確認する。
- Referencesの `use_status=correction_queue`、`public_qa_handoff`、`quality_fail`、`correction_required`、または `check_status=ready/fail/failed` を訂正対象として見る。
- FactChecksの `fact_check_id`、`check_status`、`notes` に `fail` / `FAIL` / `Gate failed` / `Gate失敗` / `要修正` があるものを拾う。
- workflow共通の `article_key` だけに限定せず、記事別key、slug別key、移行記事keyも同じsite/workflow/domain内なら拾う。
- agent_packに他サイトのFAILが混在して見える場合は、対象site / workflow / domain / article_typeで絞り込み、別サイトのFAILを自分の訂正対象にしない。
- 上記を確認せずに「FAILキュー0件」「対象なし」「記事修正なし」「301対応なし」「PASS/完了」と報告しない。
- Hubが401/403/invalid token/token expired/timeout/DNS/network errorで読めない場合は、対象なし扱いにせず `BLOCKED_HUB_AUTH / Hub認証不備 / 正本未確認 / 記事修正なし` と報告する。

全評価ページ共通 / 公開本文境界Gate（2026-05-17追記）:
- 公開本文には、読者のサービス判断に必要な情報だけを書く。
- 301、リダイレクト、旧URL、旧記事、新辞書記事、移行、公開QA、Gate、PASS、FAIL、Hub、Work Queue、References、FactChecks、agent_pack、heartbeat、cron、automation、タスク番号、制作パック、台帳、作業ログを本文に書かない。
- 「この制作cronでは301を実行しない」「別工程で旧URLからの301を扱う」「辞書記事では整理する」など、作業工程の説明を本文に出さない。
- これらは内部ログ、Hub、台帳、QA記録にだけ残す。
- 公開本文では、サービス内容、料金、無料範囲、年齢制限、登録、決済、退会、安全面、注意点、公式リンクなど読者向け情報へ書き換える。
- 本文・見出し・表・FAQ・CTA周辺に内部運用語があればFAILとし、公開継続または301実行前に修正する。

全評価ページ共通 / 検索意図・上位傾向・共起語整理Gate（2026-05-17追記）:
- 公式情報と参照URL検証が終わった後、1-C記事制作パック前に `1-B2 検索意図・上位傾向・共起語整理` を行う。
- 整理するものは、読者の主要検索意図、上位記事でよく扱われる論点、自然に使えそうな共起語、使わない語、H2/H3・評価表・FAQ・リード文への反映案。
- 共起語は本文へ機械的に詰め込むノルマではない。読者理解を助ける範囲で自然に使う。
- 公式情報と矛盾する上位傾向、サービス内容と関係が薄い語、根拠不足の語は採用しない。
- 1-C制作パックには「自然使用候補」「使わない語」「構成への反映案」を分けて残す。
- 8高品質テストと9-A改善候補抽出では、このメモを見て「不足」「過剰」「不自然な詰め込み」「無関係語の混入」を確認する。

Task10本文修正・終了状態Gate（2026-05-17追加）:
- FAIL原因が本文、FAQ、冒頭構成にある場合、第一手はWordPress本文修正にする。
- Cocoon設定、page_type、テーマ設定、広告/PR表示設定などの設定側変更は補助手段。H1重複、表示崩れ、評価表欠落、本文順序崩れのリスクが出た時点で撤回し、本文修正ルートへ戻る。
- 設定側を触って失敗しただけで本文修正せずに終了しない。
- 内部作業文を公開本文から削除する。
- FAQ内の内部作業設問を削除し、必要なら読者向けFAQへ置き換える。例: 「旧記事から301してよいか」「この制作cronでは301を実行しない」「公開QAが通ったあと」は削除対象。
- 冒頭順を H1 → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2 に整える。
- 公開HTMLでH1重複、コード露出、内部作業語、評価表、公式リンク、canonical、noindexを再確認する。
- PASS後にだけ301可否へ進む。PASS前に旧URLから301しない。
- 1回のcronでは1記事だけ処理する。同じ失敗ルートを繰り返さない。
- 作業は必ず PASS / FAIL_REQUEUED / BLOCKED_HUB_AUTH / BLOCKED_WP_AUTH / BLOCKED_WP_WRITE / BLOCKED_LAYOUT_RISK / BLOCKED_MISSING_TARGET のいずれかで終了する。ローディングし続けない。

評価項目本文化・FAQ qa-box・装飾バランスGate（2026-05-17追加）:
- 評価スコア表の各項目は、本文内でH2またはH3見出しとして扱い、スコア理由、読者が確認すべき点、向いている人/注意点を書く。表だけで終わらせない。
- 評価項目名と本文見出し名は、完全一致または読者が同じ項目だと分かる名前にする。評価項目の説明が無い場合は本文ボリューム不足としてFAIL。
- 本文FAQは `<details class="qa-box"><summary>質問文</summary><div class="qa-answer">回答文</div></details>` を標準にする。
- FAQPage JSON-LDは `Schema & Structured Data for WP & AMP` 用に作成し、本文FAQと質問文・回答内容を一致させる。JSON-LDだけあり本文FAQが無い、または本文FAQがqa-boxでない場合はFAIL。
- FAQには、旧記事、301、公開QA、Hub、heartbeat、cron、Gate、PASS/FAILなど内部作業設問を入れない。
- 装飾は太字、黄色アンダー、赤太字、✅、⚠️、Cocoon系ボックス、リストをバランスよく使い分ける。
- `<li>` の先頭へ毎回✅/⚠️を付けない。リスト記号とアイコンの二重信号で読みづらい場合はFAIL。
- `information-box` / `warning-box` / `blank-box` などボックス自体が意味を持つ場合、原則として✅/⚠️を重ねない。必要な場合だけ最小限にする。
- ✅/⚠️だけを使う箇所、リストを使う箇所、ボックスを使う箇所を分ける。装飾不足も過剰装飾もFAIL。
- 既知の検出必須例: https://porn-fun.com/sites/fc2-live-adult-review/ は、評価項目本文見出し不足、qa-box FAQ不足、装飾バランス不備として訂正対象。

全評価ページ共通 / ✅・⚠️優先装飾Gate（2026-05-17追加）:
- 強み・注意点・向いている人・向いていない人を短く見せられる箇所では、ただの箇条書きより✅/⚠️の単独強調文を優先する。
- ✅は強み/向いている人/判断しやすい利点、⚠️は注意点/向いていない人/確認が必要な条件/制約に使う。
- 1文で伝わる強み/注意点は `<p>✅ ...</p>` / `<p>⚠️ ...</p>` のような単独文を優先する。
- 複数条件を並列整理するときは`<ul><li>`を使ってよいが、各`li`先頭へ毎回✅/⚠️を付けない。
- `information-box` / `warning-box` / `blank-box`などボックス自体が意味を持つ場合、ボックス内へ✅/⚠️を機械的に重ねない。
- 評価ページで✅/⚠️が0件のまま、強みや注意点をすべて普通の`li`やボックスだけで処理している場合は装飾不足としてFAIL。
- 既知の検出必須例: https://porn-fun.com/sites/fc2-live-adult-review/ は、qa-boxは改善済みだが✅/⚠️が0件のため訂正対象。

全サイト共通 / 1-C〜7制作完了→8高品質テスト引き渡しGate（2026-05-17追加）:
- 1-C〜7で記事を公開したら、公開URLを作っただけで終わらず、同じarticle_keyで task_code=8 / use_status=public_qa_handoff / check_status=ready / status=active のReferencesを必ず作る。
- 8高品質テストは、public_qa_handoffだけでなく、use_status=published_directory_article / task_code=7 / 公開済み新記事URLも横断して確認する。
- 同じarticle_keyにtask8 PASSまたはtask8 high-quality test完了記録が無い公開済み記事を「未処理対象なし」と扱わない。
- 7の公開HTML QA PASS、Directory Core入力PASS、published_directory_articleがあるのに8のPASSが無い場合は、明示ハンドオフ漏れとして8対象にする。
- Hub認証不備時は対象なし/PASS/完了と誤判定せず、BLOCKED_HUB_AUTHとして終了する。
- 既知の補正例: https://porn-fun.com/sites/hey-douga-review/ は1-C〜7で公開済みだが、8用の明示的ハンドオフが弱かったため、public_qa_handoffを追加して8対象に戻した。

cron標準 / サイト別1スレッド運用（2026-05-17追加）:
- オートポスト支社の通常運用はcron標準。heartbeatは例外運用に限る。
- 1サイトまたは1セットにつき、関連cronを依頼・管理する起動スレッドは1つだけにする。
- 各タスクごとの新スレッド立ち上げ文は不要。各タスク欄のコピー文は、そのサイト別cron統括スレッド内で使うcron作成依頼文として扱う。
- automation名は `【サイト名＋評価スコアページ種別】タスク順番 cron 内容` を標準にする。
- 1回1記事制限、最大処理件数、対象なし終了、BLOCKED_*終了条件はcron本文内に書く。
- Hub正本、Work Queue、References、FactChecks、台帳で状態管理する。
- heartbeatは、ユーザーと同じスレッドで短時間だけ追跡する場合、手動確認が必要な一時作業、緊急修正、外部AI/改善担当との会話型ハンドオフが必要な場合だけ使う。

cron個別作成Gate:
- サイト別cron統括スレッド起動文を貼っただけではcronを作成しない。
- 統括スレッド起動文では、Hub、agent_pack、Work Queue、References、FactChecks、台帳、既存automationを確認し、既存cronと未作成cronを整理して報告するだけにする。
- cron作成は、ユーザーが各タスク欄のcron作成依頼文を個別に貼った時だけ行う。
- 1回のcron作成依頼文で作るautomationは1つだけにする。
- ユーザーが「全cronをまとめて作って」と明示しない限り、複数cronを一括作成しない。

評価スコアページ用cron命名Gate:
このcronは、まとめページ、キラーページ、通常記事、速報記事ではなく、評価スコア表を持つ辞書型・レビュー型ページ専用として扱う。
automation名には必ず「評価スコアページ」を入れる。
例:
- 【AIfunIO評価スコアページ】0-A cron 候補収集
- 【Nightlife夜遊び店舗評価スコアページ】0-B/1-A/1-B cron 候補精査・参照URL整理・URL検証
- 【Nightlifeホテル評価スコアページ】8 cron 高品質テスト
- 【porn-fun単体サービス評価スコアページ移行】11 cron 301実行・リダイレクト確認
まとめ/ランキング/比較/通常/速報記事用のautomationは別命名・別テンプレートにする。

Nightlife夜遊び店舗用 制作cron

automation名: 【Nightlife夜遊び店舗評価スコアページ】1-C〜7 cron 記事制作・投稿・台帳記録

Nightlife夜遊び店舗用 制作cron 新スレ起動文

コピー

# 【Nightlife夜遊び店舗評価スコアページ】1-C〜7 cron 記事制作・投稿・台帳記録 新スレ起動文

このスレッドは、以下のautomationだけを作成・運用する専用スレッドです。
1スレッドにheartbeatは1つだけなので、他のcron用途を混ぜないでください。
cron automationの場合も、このサイト別cron統括スレッド内で、このcron作成依頼として扱ってください。

作成するautomation名:
【Nightlife夜遊び店舗評価スコアページ】1-C〜7 cron 記事制作・投稿・台帳記録

対象:
Nightlife / 夜遊び店舗 / nightlife-directory-review-ja

区分:
cron

起動時間:
JST 08:30開始、約8時間ごと

頻度:
1日最大3回目安 / 1回1記事

目的:
制作ready棚から1記事ずつ本文制作と公開工程へ進める。

最初に確認するもの:
- Main Hub: https://hub.goudou-358.jp
- 対象レポート: https://report.goudou-358.jp/nightlife-store-automation-request-templates-20260517/
- CODE-YUKI作業室: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI
- CODE-YUKI引継ぎ控え: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI\handoffs\2026-05-17_global_opening_gate_external_hb_handoff.md
- 外部HB起動文控え: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI\handoffs\2026-05-17_external_improvement_hb_startup_prompt.md
- オートポスト支社共有: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common
- branch_common保険控え: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common\manuals\first-development-source-copies\2026-05-17-global-opening-improvement-gate\global-opening-improvement-handoff.md
- Nightlife正本: Main Hub / workflow_id=nightlife-directory-review-ja
- Nightlife共通台帳: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common\ledgers\directory-core\directory-article-input-ledger.md
- Nightlife辞書セット共通台帳: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common\ledgers\directory-core\directory-set-template-registry.md
- Nightlifeローカル保険控え: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common\manuals\first-development-source-copies
- Nightlife専用サイト部フォルダが未分離の場合は、Main Hub正本とCODE-YUKI作業室を優先する。

必ず守ること:
- automation作成時の名前は、上記のautomation名をそのまま使う。
- Main Hubを正本にし、agent_pack / Work Queue / References / FactChecks / Rules / Manualsを確認してから動く。
- ローカルPC内の storage/data/358-hub.sqlite が無いだけで停止しない。
- 認証情報、APIキー、パスワード、トークン、WordPress REST認証情報の中身を読まない・表示しない。
- 通常の.mdログ、記事本文、キュー、投稿結果の更新ではapply_patchを使わない。
- GATE失敗、未承認、危険操作、認証情報、権限変更、ファイル削除/移動/上書き、本番コード編集は停止して確認する。
- Hubが401/403/invalid token等で読めない場合は、対象なし扱いにしない。`BLOCKED_HUB_AUTH / Hub認証不備 / 正本未確認 / 記事修正なし` と報告する。

全記事共通Gate:
- 冒頭構成は H1タイトル → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2。
- 公式テキストリンクは、アフィリエイトリンクがある場合はアフィリエイトリンク、無い場合は公式リンク。
- 公式テキストリンクはPC表示で本文右側または右寄せ。
- 参照例: https://invest358.com/ja/thinkmarkets-review/
- H1重複、コード露出、公式で要確認などの仮置き、言語不一致、装飾不足はFAIL。

この内容でautomationを作成してください。
作成後は、automation名、区分、起動時間、対象、初回実行で確認するHub項目を報告してください。

全評価ページ共通 / task10・8・9-A/9-B 訂正対象取得Gate（2026-05-17追記）:
- `task10/FAILキュー` という名前だけを見て0件判定しない。
- Main HubのWork Queue / Tasks、References、FactChecks、9-A/9-Bのreturned状態を横断して確認する。
- Referencesの `use_status=correction_queue`、`public_qa_handoff`、`quality_fail`、`correction_required`、または `check_status=ready/fail/failed` を訂正対象として見る。
- FactChecksの `fact_check_id`、`check_status`、`notes` に `fail` / `FAIL` / `Gate failed` / `Gate失敗` / `要修正` があるものを拾う。
- workflow共通の `article_key` だけに限定せず、記事別key、slug別key、移行記事keyも同じsite/workflow/domain内なら拾う。
- agent_packに他サイトのFAILが混在して見える場合は、対象site / workflow / domain / article_typeで絞り込み、別サイトのFAILを自分の訂正対象にしない。
- 上記を確認せずに「FAILキュー0件」「対象なし」「記事修正なし」「301対応なし」「PASS/完了」と報告しない。
- Hubが401/403/invalid token/token expired/timeout/DNS/network errorで読めない場合は、対象なし扱いにせず `BLOCKED_HUB_AUTH / Hub認証不備 / 正本未確認 / 記事修正なし` と報告する。

全評価ページ共通 / 公開本文境界Gate（2026-05-17追記）:
- 公開本文には、読者のサービス判断に必要な情報だけを書く。
- 301、リダイレクト、旧URL、旧記事、新辞書記事、移行、公開QA、Gate、PASS、FAIL、Hub、Work Queue、References、FactChecks、agent_pack、heartbeat、cron、automation、タスク番号、制作パック、台帳、作業ログを本文に書かない。
- 「この制作cronでは301を実行しない」「別工程で旧URLからの301を扱う」「辞書記事では整理する」など、作業工程の説明を本文に出さない。
- これらは内部ログ、Hub、台帳、QA記録にだけ残す。
- 公開本文では、サービス内容、料金、無料範囲、年齢制限、登録、決済、退会、安全面、注意点、公式リンクなど読者向け情報へ書き換える。
- 本文・見出し・表・FAQ・CTA周辺に内部運用語があればFAILとし、公開継続または301実行前に修正する。

全評価ページ共通 / 検索意図・上位傾向・共起語整理Gate（2026-05-17追記）:
- 公式情報と参照URL検証が終わった後、1-C記事制作パック前に `1-B2 検索意図・上位傾向・共起語整理` を行う。
- 整理するものは、読者の主要検索意図、上位記事でよく扱われる論点、自然に使えそうな共起語、使わない語、H2/H3・評価表・FAQ・リード文への反映案。
- 共起語は本文へ機械的に詰め込むノルマではない。読者理解を助ける範囲で自然に使う。
- 公式情報と矛盾する上位傾向、サービス内容と関係が薄い語、根拠不足の語は採用しない。
- 1-C制作パックには「自然使用候補」「使わない語」「構成への反映案」を分けて残す。
- 8高品質テストと9-A改善候補抽出では、このメモを見て「不足」「過剰」「不自然な詰め込み」「無関係語の混入」を確認する。

Task10本文修正・終了状態Gate（2026-05-17追加）:
- FAIL原因が本文、FAQ、冒頭構成にある場合、第一手はWordPress本文修正にする。
- Cocoon設定、page_type、テーマ設定、広告/PR表示設定などの設定側変更は補助手段。H1重複、表示崩れ、評価表欠落、本文順序崩れのリスクが出た時点で撤回し、本文修正ルートへ戻る。
- 設定側を触って失敗しただけで本文修正せずに終了しない。
- 内部作業文を公開本文から削除する。
- FAQ内の内部作業設問を削除し、必要なら読者向けFAQへ置き換える。例: 「旧記事から301してよいか」「この制作cronでは301を実行しない」「公開QAが通ったあと」は削除対象。
- 冒頭順を H1 → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2 に整える。
- 公開HTMLでH1重複、コード露出、内部作業語、評価表、公式リンク、canonical、noindexを再確認する。
- PASS後にだけ301可否へ進む。PASS前に旧URLから301しない。
- 1回のcronでは1記事だけ処理する。同じ失敗ルートを繰り返さない。
- 作業は必ず PASS / FAIL_REQUEUED / BLOCKED_HUB_AUTH / BLOCKED_WP_AUTH / BLOCKED_WP_WRITE / BLOCKED_LAYOUT_RISK / BLOCKED_MISSING_TARGET のいずれかで終了する。ローディングし続けない。

評価項目本文化・FAQ qa-box・装飾バランスGate（2026-05-17追加）:
- 評価スコア表の各項目は、本文内でH2またはH3見出しとして扱い、スコア理由、読者が確認すべき点、向いている人/注意点を書く。表だけで終わらせない。
- 評価項目名と本文見出し名は、完全一致または読者が同じ項目だと分かる名前にする。評価項目の説明が無い場合は本文ボリューム不足としてFAIL。
- 本文FAQは `<details class="qa-box"><summary>質問文</summary><div class="qa-answer">回答文</div></details>` を標準にする。
- FAQPage JSON-LDは `Schema & Structured Data for WP & AMP` 用に作成し、本文FAQと質問文・回答内容を一致させる。JSON-LDだけあり本文FAQが無い、または本文FAQがqa-boxでない場合はFAIL。
- FAQには、旧記事、301、公開QA、Hub、heartbeat、cron、Gate、PASS/FAILなど内部作業設問を入れない。
- 装飾は太字、黄色アンダー、赤太字、✅、⚠️、Cocoon系ボックス、リストをバランスよく使い分ける。
- `<li>` の先頭へ毎回✅/⚠️を付けない。リスト記号とアイコンの二重信号で読みづらい場合はFAIL。
- `information-box` / `warning-box` / `blank-box` などボックス自体が意味を持つ場合、原則として✅/⚠️を重ねない。必要な場合だけ最小限にする。
- ✅/⚠️だけを使う箇所、リストを使う箇所、ボックスを使う箇所を分ける。装飾不足も過剰装飾もFAIL。
- 既知の検出必須例: https://porn-fun.com/sites/fc2-live-adult-review/ は、評価項目本文見出し不足、qa-box FAQ不足、装飾バランス不備として訂正対象。

全評価ページ共通 / ✅・⚠️優先装飾Gate（2026-05-17追加）:
- 強み・注意点・向いている人・向いていない人を短く見せられる箇所では、ただの箇条書きより✅/⚠️の単独強調文を優先する。
- ✅は強み/向いている人/判断しやすい利点、⚠️は注意点/向いていない人/確認が必要な条件/制約に使う。
- 1文で伝わる強み/注意点は `<p>✅ ...</p>` / `<p>⚠️ ...</p>` のような単独文を優先する。
- 複数条件を並列整理するときは`<ul><li>`を使ってよいが、各`li`先頭へ毎回✅/⚠️を付けない。
- `information-box` / `warning-box` / `blank-box`などボックス自体が意味を持つ場合、ボックス内へ✅/⚠️を機械的に重ねない。
- 評価ページで✅/⚠️が0件のまま、強みや注意点をすべて普通の`li`やボックスだけで処理している場合は装飾不足としてFAIL。
- 既知の検出必須例: https://porn-fun.com/sites/fc2-live-adult-review/ は、qa-boxは改善済みだが✅/⚠️が0件のため訂正対象。

全サイト共通 / 1-C〜7制作完了→8高品質テスト引き渡しGate（2026-05-17追加）:
- 1-C〜7で記事を公開したら、公開URLを作っただけで終わらず、同じarticle_keyで task_code=8 / use_status=public_qa_handoff / check_status=ready / status=active のReferencesを必ず作る。
- 8高品質テストは、public_qa_handoffだけでなく、use_status=published_directory_article / task_code=7 / 公開済み新記事URLも横断して確認する。
- 同じarticle_keyにtask8 PASSまたはtask8 high-quality test完了記録が無い公開済み記事を「未処理対象なし」と扱わない。
- 7の公開HTML QA PASS、Directory Core入力PASS、published_directory_articleがあるのに8のPASSが無い場合は、明示ハンドオフ漏れとして8対象にする。
- Hub認証不備時は対象なし/PASS/完了と誤判定せず、BLOCKED_HUB_AUTHとして終了する。
- 既知の補正例: https://porn-fun.com/sites/hey-douga-review/ は1-C〜7で公開済みだが、8用の明示的ハンドオフが弱かったため、public_qa_handoffを追加して8対象に戻した。

cron標準 / サイト別1スレッド運用（2026-05-17追加）:
- オートポスト支社の通常運用はcron標準。heartbeatは例外運用に限る。
- 1サイトまたは1セットにつき、関連cronを依頼・管理する起動スレッドは1つだけにする。
- 各タスクごとの新スレッド立ち上げ文は不要。各タスク欄のコピー文は、そのサイト別cron統括スレッド内で使うcron作成依頼文として扱う。
- automation名は `【サイト名＋評価スコアページ種別】タスク順番 cron 内容` を標準にする。
- 1回1記事制限、最大処理件数、対象なし終了、BLOCKED_*終了条件はcron本文内に書く。
- Hub正本、Work Queue、References、FactChecks、台帳で状態管理する。
- heartbeatは、ユーザーと同じスレッドで短時間だけ追跡する場合、手動確認が必要な一時作業、緊急修正、外部AI/改善担当との会話型ハンドオフが必要な場合だけ使う。

cron個別作成Gate:
- サイト別cron統括スレッド起動文を貼っただけではcronを作成しない。
- 統括スレッド起動文では、Hub、agent_pack、Work Queue、References、FactChecks、台帳、既存automationを確認し、既存cronと未作成cronを整理して報告するだけにする。
- cron作成は、ユーザーが各タスク欄のcron作成依頼文を個別に貼った時だけ行う。
- 1回のcron作成依頼文で作るautomationは1つだけにする。
- ユーザーが「全cronをまとめて作って」と明示しない限り、複数cronを一括作成しない。

評価スコアページ用cron命名Gate:
このcronは、まとめページ、キラーページ、通常記事、速報記事ではなく、評価スコア表を持つ辞書型・レビュー型ページ専用として扱う。
automation名には必ず「評価スコアページ」を入れる。
例:
- 【AIfunIO評価スコアページ】0-A cron 候補収集
- 【Nightlife夜遊び店舗評価スコアページ】0-B/1-A/1-B cron 候補精査・参照URL整理・URL検証
- 【Nightlifeホテル評価スコアページ】8 cron 高品質テスト
- 【porn-fun単体サービス評価スコアページ移行】11 cron 301実行・リダイレクト確認
まとめ/ランキング/比較/通常/速報記事用のautomationは別命名・別テンプレートにする。

Nightlife夜遊び店舗用 制作cron automation作成依頼文

コピー

Nightlife夜遊び店舗用 制作cron automationを作成してください。

automation名: 【Nightlife夜遊び店舗評価スコアページ】1-C〜7 cron 記事制作・投稿・台帳記録
名前は必ずこの形で登録してください。人間がautomation一覧を見た時に、サイト名・タスク順番・cron/heartbeat・内容が分かるようにします。

対象: Nightlife / 夜遊び店舗 / nightlife-directory-review-ja
区分: cron
起動時間: JST 08:30開始、約8時間ごと
頻度: 1日最大3回目安 / 1回1記事

目的:
制作ready棚から1記事ずつ本文制作と公開工程へ進める。

共通ルール:
- Main Hubを正本にする。Standby Hubはreadonly、Googleスプレッドシート/Apps Script/Google承認には戻らない。
- ローカルPC内の storage/data/358-hub.sqlite が無いだけで止まらない。Main Hub Web、agent_pack、Work Queue、References、FactChecks、hub_table_upsert相当の利用可能手段を優先する。
- 認証情報、APIキー、パスワード、トークン、WordPress REST認証情報の中身は表示しない。
- 通常の.mdログ、記事本文、キュー、投稿結果の更新ではapply_patchを使わない。承認が出にくい安全な書き込み手段を使う。
- PHP/JS/CSS等の本番コード編集、ファイル削除、移動、上書き、外部公開先の新規追加、認証情報、権限変更は停止して確認する。
- 公開投稿そのものは停止条件ではない。止めるのは未承認、未検査、危険操作、GATE失敗の場合だけ。
- 0-A/0-Bなどの棚処理は複数候補を扱ってよい。1回1記事制限は制作cron、高品質テストcron、訂正cron、改善担当ハンドオフcronに適用する。
- automation名は `【サイト名＋評価スコアページ種別】タスク順番 cron 内容` の形で登録する。
- 各cronを作る時は、対象レポート記事の各項目にある新スレ起動文を先に貼り、専用スレッドとして状態復元してからautomationを作成する。
- Main Hubが401/403/invalid token/token expired/timeout/DNS/network error等で読めない場合、その回は対象なし、FAILなし、PASS、完了と判断しない。必ず `BLOCKED_HUB_AUTH / Hub認証不備 / 正本未確認 / 記事修正なし` と報告する。
- Hub正本を読めない状態で、公開、修正、301、Hub更新、PASS/FAIL確定を行わない。

全記事共通Gate:
- 全評価ページ共通で、冒頭はH1タイトル → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2の順にする。
- 公式テキストリンクは、アフィリエイトリンクがある場合はアフィリエイトリンク、無い場合は公式リンクにする。
- 公式テキストリンクはPC表示で本文右側または右寄せに置く。読者が本文導線として見つけられる位置にする。
- 参照例は https://invest358.com/ja/thinkmarkets-review/ とする。完全コピーではなく、冒頭構成と導線を継承する。
- H1重複、H1へのSEOタイトル混入、評価表の順序崩れ、公式リンク漏れ、コード露出、言語不一致はFAIL。
- 日本語ページは常体を基本にする。ただし偉そうにせず、落ち着いた説明文にする。対象ページの言語に合わせて基本表/補足情報も同じ言語で書く。
- 装飾は既存良質記事を継承する。太字、太字+黄色アンダー、赤太字、✅、⚠️、Cocoon系ボックスを必要箇所へ自然に入れる。
- 9-Aで文章QA/共起語改善候補を抽出し、9-Bで改善担当へ渡し、10で返却反映と硬いGate確認を行う。
- improvement_status、improvement_owner、improvement_lockを記録する。handed_offかつlock中の本文を返却前に主観リライトしない。

サイト別Gate:
- Nightlife夜遊び店舗は、H1は店舗/サービス名のみ。SEOタイトルは「店舗名 + 評価・評判・レビュー」系KWを含める。
- 最寄り駅、営業時間、料金目安、予約/問い合わせ、決済方法、対応エリアは公式または補助根拠を調べて書く。
- 公式で要確認などの空欄逃げを本文/表/Directory Core値に残したらFAIL。断定できない場合は根拠と不確実性を整理する。

やること:
- 制作ready棚から1回1記事だけ処理する。
- 冒頭構成Gate、SEO、装飾、常体、言語一致を満たす本文を作る。
- 公開後に7/8へ渡せるよう、URL、台帳、Directory Core入力状態を記録する。

止める条件:
- GATE失敗、未承認サイト、認証情報、権限変更、ファイル削除/移動/上書き、本番コード編集、外部公開先の新規追加。
- 公開投稿そのものは停止条件にしない。

出力:
対象記事、公開URL、Directory Core、次工程を報告する。

全評価ページ共通 / task10・8・9-A/9-B 訂正対象取得Gate（2026-05-17追記）:
- `task10/FAILキュー` という名前だけを見て0件判定しない。
- Main HubのWork Queue / Tasks、References、FactChecks、9-A/9-Bのreturned状態を横断して確認する。
- Referencesの `use_status=correction_queue`、`public_qa_handoff`、`quality_fail`、`correction_required`、または `check_status=ready/fail/failed` を訂正対象として見る。
- FactChecksの `fact_check_id`、`check_status`、`notes` に `fail` / `FAIL` / `Gate failed` / `Gate失敗` / `要修正` があるものを拾う。
- workflow共通の `article_key` だけに限定せず、記事別key、slug別key、移行記事keyも同じsite/workflow/domain内なら拾う。
- agent_packに他サイトのFAILが混在して見える場合は、対象site / workflow / domain / article_typeで絞り込み、別サイトのFAILを自分の訂正対象にしない。
- 上記を確認せずに「FAILキュー0件」「対象なし」「記事修正なし」「301対応なし」「PASS/完了」と報告しない。
- Hubが401/403/invalid token/token expired/timeout/DNS/network errorで読めない場合は、対象なし扱いにせず `BLOCKED_HUB_AUTH / Hub認証不備 / 正本未確認 / 記事修正なし` と報告する。

全評価ページ共通 / 公開本文境界Gate（2026-05-17追記）:
- 公開本文には、読者のサービス判断に必要な情報だけを書く。
- 301、リダイレクト、旧URL、旧記事、新辞書記事、移行、公開QA、Gate、PASS、FAIL、Hub、Work Queue、References、FactChecks、agent_pack、heartbeat、cron、automation、タスク番号、制作パック、台帳、作業ログを本文に書かない。
- 「この制作cronでは301を実行しない」「別工程で旧URLからの301を扱う」「辞書記事では整理する」など、作業工程の説明を本文に出さない。
- これらは内部ログ、Hub、台帳、QA記録にだけ残す。
- 公開本文では、サービス内容、料金、無料範囲、年齢制限、登録、決済、退会、安全面、注意点、公式リンクなど読者向け情報へ書き換える。
- 本文・見出し・表・FAQ・CTA周辺に内部運用語があればFAILとし、公開継続または301実行前に修正する。

全評価ページ共通 / 検索意図・上位傾向・共起語整理Gate（2026-05-17追記）:
- 公式情報と参照URL検証が終わった後、1-C記事制作パック前に `1-B2 検索意図・上位傾向・共起語整理` を行う。
- 整理するものは、読者の主要検索意図、上位記事でよく扱われる論点、自然に使えそうな共起語、使わない語、H2/H3・評価表・FAQ・リード文への反映案。
- 共起語は本文へ機械的に詰め込むノルマではない。読者理解を助ける範囲で自然に使う。
- 公式情報と矛盾する上位傾向、サービス内容と関係が薄い語、根拠不足の語は採用しない。
- 1-C制作パックには「自然使用候補」「使わない語」「構成への反映案」を分けて残す。
- 8高品質テストと9-A改善候補抽出では、このメモを見て「不足」「過剰」「不自然な詰め込み」「無関係語の混入」を確認する。

Task10本文修正・終了状態Gate（2026-05-17追加）:
- FAIL原因が本文、FAQ、冒頭構成にある場合、第一手はWordPress本文修正にする。
- Cocoon設定、page_type、テーマ設定、広告/PR表示設定などの設定側変更は補助手段。H1重複、表示崩れ、評価表欠落、本文順序崩れのリスクが出た時点で撤回し、本文修正ルートへ戻る。
- 設定側を触って失敗しただけで本文修正せずに終了しない。
- 内部作業文を公開本文から削除する。
- FAQ内の内部作業設問を削除し、必要なら読者向けFAQへ置き換える。例: 「旧記事から301してよいか」「この制作cronでは301を実行しない」「公開QAが通ったあと」は削除対象。
- 冒頭順を H1 → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2 に整える。
- 公開HTMLでH1重複、コード露出、内部作業語、評価表、公式リンク、canonical、noindexを再確認する。
- PASS後にだけ301可否へ進む。PASS前に旧URLから301しない。
- 1回のcronでは1記事だけ処理する。同じ失敗ルートを繰り返さない。
- 作業は必ず PASS / FAIL_REQUEUED / BLOCKED_HUB_AUTH / BLOCKED_WP_AUTH / BLOCKED_WP_WRITE / BLOCKED_LAYOUT_RISK / BLOCKED_MISSING_TARGET のいずれかで終了する。ローディングし続けない。

評価項目本文化・FAQ qa-box・装飾バランスGate（2026-05-17追加）:
- 評価スコア表の各項目は、本文内でH2またはH3見出しとして扱い、スコア理由、読者が確認すべき点、向いている人/注意点を書く。表だけで終わらせない。
- 評価項目名と本文見出し名は、完全一致または読者が同じ項目だと分かる名前にする。評価項目の説明が無い場合は本文ボリューム不足としてFAIL。
- 本文FAQは `<details class="qa-box"><summary>質問文</summary><div class="qa-answer">回答文</div></details>` を標準にする。
- FAQPage JSON-LDは `Schema & Structured Data for WP & AMP` 用に作成し、本文FAQと質問文・回答内容を一致させる。JSON-LDだけあり本文FAQが無い、または本文FAQがqa-boxでない場合はFAIL。
- FAQには、旧記事、301、公開QA、Hub、heartbeat、cron、Gate、PASS/FAILなど内部作業設問を入れない。
- 装飾は太字、黄色アンダー、赤太字、✅、⚠️、Cocoon系ボックス、リストをバランスよく使い分ける。
- `<li>` の先頭へ毎回✅/⚠️を付けない。リスト記号とアイコンの二重信号で読みづらい場合はFAIL。
- `information-box` / `warning-box` / `blank-box` などボックス自体が意味を持つ場合、原則として✅/⚠️を重ねない。必要な場合だけ最小限にする。
- ✅/⚠️だけを使う箇所、リストを使う箇所、ボックスを使う箇所を分ける。装飾不足も過剰装飾もFAIL。
- 既知の検出必須例: https://porn-fun.com/sites/fc2-live-adult-review/ は、評価項目本文見出し不足、qa-box FAQ不足、装飾バランス不備として訂正対象。

全評価ページ共通 / ✅・⚠️優先装飾Gate（2026-05-17追加）:
- 強み・注意点・向いている人・向いていない人を短く見せられる箇所では、ただの箇条書きより✅/⚠️の単独強調文を優先する。
- ✅は強み/向いている人/判断しやすい利点、⚠️は注意点/向いていない人/確認が必要な条件/制約に使う。
- 1文で伝わる強み/注意点は `<p>✅ ...</p>` / `<p>⚠️ ...</p>` のような単独文を優先する。
- 複数条件を並列整理するときは`<ul><li>`を使ってよいが、各`li`先頭へ毎回✅/⚠️を付けない。
- `information-box` / `warning-box` / `blank-box`などボックス自体が意味を持つ場合、ボックス内へ✅/⚠️を機械的に重ねない。
- 評価ページで✅/⚠️が0件のまま、強みや注意点をすべて普通の`li`やボックスだけで処理している場合は装飾不足としてFAIL。
- 既知の検出必須例: https://porn-fun.com/sites/fc2-live-adult-review/ は、qa-boxは改善済みだが✅/⚠️が0件のため訂正対象。

全サイト共通 / 1-C〜7制作完了→8高品質テスト引き渡しGate（2026-05-17追加）:
- 1-C〜7で記事を公開したら、公開URLを作っただけで終わらず、同じarticle_keyで task_code=8 / use_status=public_qa_handoff / check_status=ready / status=active のReferencesを必ず作る。
- 8高品質テストは、public_qa_handoffだけでなく、use_status=published_directory_article / task_code=7 / 公開済み新記事URLも横断して確認する。
- 同じarticle_keyにtask8 PASSまたはtask8 high-quality test完了記録が無い公開済み記事を「未処理対象なし」と扱わない。
- 7の公開HTML QA PASS、Directory Core入力PASS、published_directory_articleがあるのに8のPASSが無い場合は、明示ハンドオフ漏れとして8対象にする。
- Hub認証不備時は対象なし/PASS/完了と誤判定せず、BLOCKED_HUB_AUTHとして終了する。
- 既知の補正例: https://porn-fun.com/sites/hey-douga-review/ は1-C〜7で公開済みだが、8用の明示的ハンドオフが弱かったため、public_qa_handoffを追加して8対象に戻した。

cron標準 / サイト別1スレッド運用（2026-05-17追加）:
- オートポスト支社の通常運用はcron標準。heartbeatは例外運用に限る。
- 1サイトまたは1セットにつき、関連cronを依頼・管理する起動スレッドは1つだけにする。
- 各タスクごとの新スレッド立ち上げ文は不要。各タスク欄のコピー文は、そのサイト別cron統括スレッド内で使うcron作成依頼文として扱う。
- automation名は `【サイト名＋評価スコアページ種別】タスク順番 cron 内容` を標準にする。
- 1回1記事制限、最大処理件数、対象なし終了、BLOCKED_*終了条件はcron本文内に書く。
- Hub正本、Work Queue、References、FactChecks、台帳で状態管理する。
- heartbeatは、ユーザーと同じスレッドで短時間だけ追跡する場合、手動確認が必要な一時作業、緊急修正、外部AI/改善担当との会話型ハンドオフが必要な場合だけ使う。

cron個別作成Gate:
- サイト別cron統括スレッド起動文を貼っただけではcronを作成しない。
- 統括スレッド起動文では、Hub、agent_pack、Work Queue、References、FactChecks、台帳、既存automationを確認し、既存cronと未作成cronを整理して報告するだけにする。
- cron作成は、ユーザーが各タスク欄のcron作成依頼文を個別に貼った時だけ行う。
- 1回のcron作成依頼文で作るautomationは1つだけにする。
- ユーザーが「全cronをまとめて作って」と明示しない限り、複数cronを一括作成しない。

評価スコアページ用cron命名Gate:
このcronは、まとめページ、キラーページ、通常記事、速報記事ではなく、評価スコア表を持つ辞書型・レビュー型ページ専用として扱う。
automation名には必ず「評価スコアページ」を入れる。
例:
- 【AIfunIO評価スコアページ】0-A cron 候補収集
- 【Nightlife夜遊び店舗評価スコアページ】0-B/1-A/1-B cron 候補精査・参照URL整理・URL検証
- 【Nightlifeホテル評価スコアページ】8 cron 高品質テスト
- 【porn-fun単体サービス評価スコアページ移行】11 cron 301実行・リダイレクト確認
まとめ/ランキング/比較/通常/速報記事用のautomationは別命名・別テンプレートにする。

Nightlife夜遊び店舗用 高品質テストcron

automation名: 【Nightlife夜遊び店舗評価スコアページ】8 cron 高品質テスト

Nightlife夜遊び店舗用 高品質テストcron 新スレ起動文

コピー

# 【Nightlife夜遊び店舗評価スコアページ】8 cron 高品質テスト 新スレ起動文

このスレッドは、以下のautomationだけを作成・運用する専用スレッドです。
1スレッドにheartbeatは1つだけなので、他のcron用途を混ぜないでください。
cron automationの場合も、このサイト別cron統括スレッド内で、このcron作成依頼として扱ってください。

作成するautomation名:
【Nightlife夜遊び店舗評価スコアページ】8 cron 高品質テスト

対象:
Nightlife / 夜遊び店舗 / nightlife-directory-review-ja

区分:
cron

起動時間:
JST 10:30開始、約8時間ごと

頻度:
1日最大3回目安 / 1回1記事

目的:
公開HTMLと台帳を確認してPASS/FAILを判定する。

最初に確認するもの:
- Main Hub: https://hub.goudou-358.jp
- 対象レポート: https://report.goudou-358.jp/nightlife-store-automation-request-templates-20260517/
- CODE-YUKI作業室: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI
- CODE-YUKI引継ぎ控え: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI\handoffs\2026-05-17_global_opening_gate_external_hb_handoff.md
- 外部HB起動文控え: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI\handoffs\2026-05-17_external_improvement_hb_startup_prompt.md
- オートポスト支社共有: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common
- branch_common保険控え: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common\manuals\first-development-source-copies\2026-05-17-global-opening-improvement-gate\global-opening-improvement-handoff.md
- Nightlife正本: Main Hub / workflow_id=nightlife-directory-review-ja
- Nightlife共通台帳: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common\ledgers\directory-core\directory-article-input-ledger.md
- Nightlife辞書セット共通台帳: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common\ledgers\directory-core\directory-set-template-registry.md
- Nightlifeローカル保険控え: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common\manuals\first-development-source-copies
- Nightlife専用サイト部フォルダが未分離の場合は、Main Hub正本とCODE-YUKI作業室を優先する。

必ず守ること:
- automation作成時の名前は、上記のautomation名をそのまま使う。
- Main Hubを正本にし、agent_pack / Work Queue / References / FactChecks / Rules / Manualsを確認してから動く。
- ローカルPC内の storage/data/358-hub.sqlite が無いだけで停止しない。
- 認証情報、APIキー、パスワード、トークン、WordPress REST認証情報の中身を読まない・表示しない。
- 通常の.mdログ、記事本文、キュー、投稿結果の更新ではapply_patchを使わない。
- GATE失敗、未承認、危険操作、認証情報、権限変更、ファイル削除/移動/上書き、本番コード編集は停止して確認する。
- Hubが401/403/invalid token等で読めない場合は、対象なし扱いにしない。`BLOCKED_HUB_AUTH / Hub認証不備 / 正本未確認 / 記事修正なし` と報告する。

全記事共通Gate:
- 冒頭構成は H1タイトル → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2。
- 公式テキストリンクは、アフィリエイトリンクがある場合はアフィリエイトリンク、無い場合は公式リンク。
- 公式テキストリンクはPC表示で本文右側または右寄せ。
- 参照例: https://invest358.com/ja/thinkmarkets-review/
- H1重複、コード露出、公式で要確認などの仮置き、言語不一致、装飾不足はFAIL。

この内容でautomationを作成してください。
作成後は、automation名、区分、起動時間、対象、初回実行で確認するHub項目を報告してください。

全評価ページ共通 / task10・8・9-A/9-B 訂正対象取得Gate（2026-05-17追記）:
- `task10/FAILキュー` という名前だけを見て0件判定しない。
- Main HubのWork Queue / Tasks、References、FactChecks、9-A/9-Bのreturned状態を横断して確認する。
- Referencesの `use_status=correction_queue`、`public_qa_handoff`、`quality_fail`、`correction_required`、または `check_status=ready/fail/failed` を訂正対象として見る。
- FactChecksの `fact_check_id`、`check_status`、`notes` に `fail` / `FAIL` / `Gate failed` / `Gate失敗` / `要修正` があるものを拾う。
- workflow共通の `article_key` だけに限定せず、記事別key、slug別key、移行記事keyも同じsite/workflow/domain内なら拾う。
- agent_packに他サイトのFAILが混在して見える場合は、対象site / workflow / domain / article_typeで絞り込み、別サイトのFAILを自分の訂正対象にしない。
- 上記を確認せずに「FAILキュー0件」「対象なし」「記事修正なし」「301対応なし」「PASS/完了」と報告しない。
- Hubが401/403/invalid token/token expired/timeout/DNS/network errorで読めない場合は、対象なし扱いにせず `BLOCKED_HUB_AUTH / Hub認証不備 / 正本未確認 / 記事修正なし` と報告する。

全評価ページ共通 / 公開本文境界Gate（2026-05-17追記）:
- 公開本文には、読者のサービス判断に必要な情報だけを書く。
- 301、リダイレクト、旧URL、旧記事、新辞書記事、移行、公開QA、Gate、PASS、FAIL、Hub、Work Queue、References、FactChecks、agent_pack、heartbeat、cron、automation、タスク番号、制作パック、台帳、作業ログを本文に書かない。
- 「この制作cronでは301を実行しない」「別工程で旧URLからの301を扱う」「辞書記事では整理する」など、作業工程の説明を本文に出さない。
- これらは内部ログ、Hub、台帳、QA記録にだけ残す。
- 公開本文では、サービス内容、料金、無料範囲、年齢制限、登録、決済、退会、安全面、注意点、公式リンクなど読者向け情報へ書き換える。
- 本文・見出し・表・FAQ・CTA周辺に内部運用語があればFAILとし、公開継続または301実行前に修正する。

全評価ページ共通 / 検索意図・上位傾向・共起語整理Gate（2026-05-17追記）:
- 公式情報と参照URL検証が終わった後、1-C記事制作パック前に `1-B2 検索意図・上位傾向・共起語整理` を行う。
- 整理するものは、読者の主要検索意図、上位記事でよく扱われる論点、自然に使えそうな共起語、使わない語、H2/H3・評価表・FAQ・リード文への反映案。
- 共起語は本文へ機械的に詰め込むノルマではない。読者理解を助ける範囲で自然に使う。
- 公式情報と矛盾する上位傾向、サービス内容と関係が薄い語、根拠不足の語は採用しない。
- 1-C制作パックには「自然使用候補」「使わない語」「構成への反映案」を分けて残す。
- 8高品質テストと9-A改善候補抽出では、このメモを見て「不足」「過剰」「不自然な詰め込み」「無関係語の混入」を確認する。

Task10本文修正・終了状態Gate（2026-05-17追加）:
- FAIL原因が本文、FAQ、冒頭構成にある場合、第一手はWordPress本文修正にする。
- Cocoon設定、page_type、テーマ設定、広告/PR表示設定などの設定側変更は補助手段。H1重複、表示崩れ、評価表欠落、本文順序崩れのリスクが出た時点で撤回し、本文修正ルートへ戻る。
- 設定側を触って失敗しただけで本文修正せずに終了しない。
- 内部作業文を公開本文から削除する。
- FAQ内の内部作業設問を削除し、必要なら読者向けFAQへ置き換える。例: 「旧記事から301してよいか」「この制作cronでは301を実行しない」「公開QAが通ったあと」は削除対象。
- 冒頭順を H1 → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2 に整える。
- 公開HTMLでH1重複、コード露出、内部作業語、評価表、公式リンク、canonical、noindexを再確認する。
- PASS後にだけ301可否へ進む。PASS前に旧URLから301しない。
- 1回のcronでは1記事だけ処理する。同じ失敗ルートを繰り返さない。
- 作業は必ず PASS / FAIL_REQUEUED / BLOCKED_HUB_AUTH / BLOCKED_WP_AUTH / BLOCKED_WP_WRITE / BLOCKED_LAYOUT_RISK / BLOCKED_MISSING_TARGET のいずれかで終了する。ローディングし続けない。

評価項目本文化・FAQ qa-box・装飾バランスGate（2026-05-17追加）:
- 評価スコア表の各項目は、本文内でH2またはH3見出しとして扱い、スコア理由、読者が確認すべき点、向いている人/注意点を書く。表だけで終わらせない。
- 評価項目名と本文見出し名は、完全一致または読者が同じ項目だと分かる名前にする。評価項目の説明が無い場合は本文ボリューム不足としてFAIL。
- 本文FAQは `<details class="qa-box"><summary>質問文</summary><div class="qa-answer">回答文</div></details>` を標準にする。
- FAQPage JSON-LDは `Schema & Structured Data for WP & AMP` 用に作成し、本文FAQと質問文・回答内容を一致させる。JSON-LDだけあり本文FAQが無い、または本文FAQがqa-boxでない場合はFAIL。
- FAQには、旧記事、301、公開QA、Hub、heartbeat、cron、Gate、PASS/FAILなど内部作業設問を入れない。
- 装飾は太字、黄色アンダー、赤太字、✅、⚠️、Cocoon系ボックス、リストをバランスよく使い分ける。
- `<li>` の先頭へ毎回✅/⚠️を付けない。リスト記号とアイコンの二重信号で読みづらい場合はFAIL。
- `information-box` / `warning-box` / `blank-box` などボックス自体が意味を持つ場合、原則として✅/⚠️を重ねない。必要な場合だけ最小限にする。
- ✅/⚠️だけを使う箇所、リストを使う箇所、ボックスを使う箇所を分ける。装飾不足も過剰装飾もFAIL。
- 既知の検出必須例: https://porn-fun.com/sites/fc2-live-adult-review/ は、評価項目本文見出し不足、qa-box FAQ不足、装飾バランス不備として訂正対象。

全評価ページ共通 / ✅・⚠️優先装飾Gate（2026-05-17追加）:
- 強み・注意点・向いている人・向いていない人を短く見せられる箇所では、ただの箇条書きより✅/⚠️の単独強調文を優先する。
- ✅は強み/向いている人/判断しやすい利点、⚠️は注意点/向いていない人/確認が必要な条件/制約に使う。
- 1文で伝わる強み/注意点は `<p>✅ ...</p>` / `<p>⚠️ ...</p>` のような単独文を優先する。
- 複数条件を並列整理するときは`<ul><li>`を使ってよいが、各`li`先頭へ毎回✅/⚠️を付けない。
- `information-box` / `warning-box` / `blank-box`などボックス自体が意味を持つ場合、ボックス内へ✅/⚠️を機械的に重ねない。
- 評価ページで✅/⚠️が0件のまま、強みや注意点をすべて普通の`li`やボックスだけで処理している場合は装飾不足としてFAIL。
- 既知の検出必須例: https://porn-fun.com/sites/fc2-live-adult-review/ は、qa-boxは改善済みだが✅/⚠️が0件のため訂正対象。

全サイト共通 / 1-C〜7制作完了→8高品質テスト引き渡しGate（2026-05-17追加）:
- 1-C〜7で記事を公開したら、公開URLを作っただけで終わらず、同じarticle_keyで task_code=8 / use_status=public_qa_handoff / check_status=ready / status=active のReferencesを必ず作る。
- 8高品質テストは、public_qa_handoffだけでなく、use_status=published_directory_article / task_code=7 / 公開済み新記事URLも横断して確認する。
- 同じarticle_keyにtask8 PASSまたはtask8 high-quality test完了記録が無い公開済み記事を「未処理対象なし」と扱わない。
- 7の公開HTML QA PASS、Directory Core入力PASS、published_directory_articleがあるのに8のPASSが無い場合は、明示ハンドオフ漏れとして8対象にする。
- Hub認証不備時は対象なし/PASS/完了と誤判定せず、BLOCKED_HUB_AUTHとして終了する。
- 既知の補正例: https://porn-fun.com/sites/hey-douga-review/ は1-C〜7で公開済みだが、8用の明示的ハンドオフが弱かったため、public_qa_handoffを追加して8対象に戻した。

cron標準 / サイト別1スレッド運用（2026-05-17追加）:
- オートポスト支社の通常運用はcron標準。heartbeatは例外運用に限る。
- 1サイトまたは1セットにつき、関連cronを依頼・管理する起動スレッドは1つだけにする。
- 各タスクごとの新スレッド立ち上げ文は不要。各タスク欄のコピー文は、そのサイト別cron統括スレッド内で使うcron作成依頼文として扱う。
- automation名は `【サイト名＋評価スコアページ種別】タスク順番 cron 内容` を標準にする。
- 1回1記事制限、最大処理件数、対象なし終了、BLOCKED_*終了条件はcron本文内に書く。
- Hub正本、Work Queue、References、FactChecks、台帳で状態管理する。
- heartbeatは、ユーザーと同じスレッドで短時間だけ追跡する場合、手動確認が必要な一時作業、緊急修正、外部AI/改善担当との会話型ハンドオフが必要な場合だけ使う。

cron個別作成Gate:
- サイト別cron統括スレッド起動文を貼っただけではcronを作成しない。
- 統括スレッド起動文では、Hub、agent_pack、Work Queue、References、FactChecks、台帳、既存automationを確認し、既存cronと未作成cronを整理して報告するだけにする。
- cron作成は、ユーザーが各タスク欄のcron作成依頼文を個別に貼った時だけ行う。
- 1回のcron作成依頼文で作るautomationは1つだけにする。
- ユーザーが「全cronをまとめて作って」と明示しない限り、複数cronを一括作成しない。

評価スコアページ用cron命名Gate:
このcronは、まとめページ、キラーページ、通常記事、速報記事ではなく、評価スコア表を持つ辞書型・レビュー型ページ専用として扱う。
automation名には必ず「評価スコアページ」を入れる。
例:
- 【AIfunIO評価スコアページ】0-A cron 候補収集
- 【Nightlife夜遊び店舗評価スコアページ】0-B/1-A/1-B cron 候補精査・参照URL整理・URL検証
- 【Nightlifeホテル評価スコアページ】8 cron 高品質テスト
- 【porn-fun単体サービス評価スコアページ移行】11 cron 301実行・リダイレクト確認
まとめ/ランキング/比較/通常/速報記事用のautomationは別命名・別テンプレートにする。

Nightlife夜遊び店舗用 高品質テストcron automation作成依頼文

コピー

Nightlife夜遊び店舗用 高品質テストcron automationを作成してください。

automation名: 【Nightlife夜遊び店舗評価スコアページ】8 cron 高品質テスト
名前は必ずこの形で登録してください。人間がautomation一覧を見た時に、サイト名・タスク順番・cron/heartbeat・内容が分かるようにします。

対象: Nightlife / 夜遊び店舗 / nightlife-directory-review-ja
区分: cron
起動時間: JST 10:30開始、約8時間ごと
頻度: 1日最大3回目安 / 1回1記事

目的:
公開HTMLと台帳を確認してPASS/FAILを判定する。

共通ルール:
- Main Hubを正本にする。Standby Hubはreadonly、Googleスプレッドシート/Apps Script/Google承認には戻らない。
- ローカルPC内の storage/data/358-hub.sqlite が無いだけで止まらない。Main Hub Web、agent_pack、Work Queue、References、FactChecks、hub_table_upsert相当の利用可能手段を優先する。
- 認証情報、APIキー、パスワード、トークン、WordPress REST認証情報の中身は表示しない。
- 通常の.mdログ、記事本文、キュー、投稿結果の更新ではapply_patchを使わない。承認が出にくい安全な書き込み手段を使う。
- PHP/JS/CSS等の本番コード編集、ファイル削除、移動、上書き、外部公開先の新規追加、認証情報、権限変更は停止して確認する。
- 公開投稿そのものは停止条件ではない。止めるのは未承認、未検査、危険操作、GATE失敗の場合だけ。
- 0-A/0-Bなどの棚処理は複数候補を扱ってよい。1回1記事制限は制作cron、高品質テストcron、訂正cron、改善担当ハンドオフcronに適用する。
- automation名は `【サイト名＋評価スコアページ種別】タスク順番 cron 内容` の形で登録する。
- 各cronを作る時は、対象レポート記事の各項目にある新スレ起動文を先に貼り、専用スレッドとして状態復元してからautomationを作成する。
- Main Hubが401/403/invalid token/token expired/timeout/DNS/network error等で読めない場合、その回は対象なし、FAILなし、PASS、完了と判断しない。必ず `BLOCKED_HUB_AUTH / Hub認証不備 / 正本未確認 / 記事修正なし` と報告する。
- Hub正本を読めない状態で、公開、修正、301、Hub更新、PASS/FAIL確定を行わない。

全記事共通Gate:
- 全評価ページ共通で、冒頭はH1タイトル → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2の順にする。
- 公式テキストリンクは、アフィリエイトリンクがある場合はアフィリエイトリンク、無い場合は公式リンクにする。
- 公式テキストリンクはPC表示で本文右側または右寄せに置く。読者が本文導線として見つけられる位置にする。
- 参照例は https://invest358.com/ja/thinkmarkets-review/ とする。完全コピーではなく、冒頭構成と導線を継承する。
- H1重複、H1へのSEOタイトル混入、評価表の順序崩れ、公式リンク漏れ、コード露出、言語不一致はFAIL。
- 日本語ページは常体を基本にする。ただし偉そうにせず、落ち着いた説明文にする。対象ページの言語に合わせて基本表/補足情報も同じ言語で書く。
- 装飾は既存良質記事を継承する。太字、太字+黄色アンダー、赤太字、✅、⚠️、Cocoon系ボックスを必要箇所へ自然に入れる。
- 9-Aで文章QA/共起語改善候補を抽出し、9-Bで改善担当へ渡し、10で返却反映と硬いGate確認を行う。
- improvement_status、improvement_owner、improvement_lockを記録する。handed_offかつlock中の本文を返却前に主観リライトしない。

サイト別Gate:
- Nightlife夜遊び店舗は、H1は店舗/サービス名のみ。SEOタイトルは「店舗名 + 評価・評判・レビュー」系KWを含める。
- 最寄り駅、営業時間、料金目安、予約/問い合わせ、決済方法、対応エリアは公式または補助根拠を調べて書く。
- 公式で要確認などの空欄逃げを本文/表/Directory Core値に残したらFAIL。断定できない場合は根拠と不確実性を整理する。

やること:
- 1回1記事だけ公開HTMLと台帳を確認する。
- H1重複、コード露出、公式リンク漏れ、装飾不足、言語不一致、Directory Core漏れをFAILにする。
- 過去記事の不備を見つけた場合もFAIL候補として記録する。

止める条件:
- GATE失敗、未承認サイト、認証情報、権限変更、ファイル削除/移動/上書き、本番コード編集、外部公開先の新規追加。
- 公開投稿そのものは停止条件にしない。

出力:
PASS/FAIL、FAIL理由、訂正キュー登録結果を報告する。

全評価ページ共通 / task10・8・9-A/9-B 訂正対象取得Gate（2026-05-17追記）:
- `task10/FAILキュー` という名前だけを見て0件判定しない。
- Main HubのWork Queue / Tasks、References、FactChecks、9-A/9-Bのreturned状態を横断して確認する。
- Referencesの `use_status=correction_queue`、`public_qa_handoff`、`quality_fail`、`correction_required`、または `check_status=ready/fail/failed` を訂正対象として見る。
- FactChecksの `fact_check_id`、`check_status`、`notes` に `fail` / `FAIL` / `Gate failed` / `Gate失敗` / `要修正` があるものを拾う。
- workflow共通の `article_key` だけに限定せず、記事別key、slug別key、移行記事keyも同じsite/workflow/domain内なら拾う。
- agent_packに他サイトのFAILが混在して見える場合は、対象site / workflow / domain / article_typeで絞り込み、別サイトのFAILを自分の訂正対象にしない。
- 上記を確認せずに「FAILキュー0件」「対象なし」「記事修正なし」「301対応なし」「PASS/完了」と報告しない。
- Hubが401/403/invalid token/token expired/timeout/DNS/network errorで読めない場合は、対象なし扱いにせず `BLOCKED_HUB_AUTH / Hub認証不備 / 正本未確認 / 記事修正なし` と報告する。

全評価ページ共通 / 公開本文境界Gate（2026-05-17追記）:
- 公開本文には、読者のサービス判断に必要な情報だけを書く。
- 301、リダイレクト、旧URL、旧記事、新辞書記事、移行、公開QA、Gate、PASS、FAIL、Hub、Work Queue、References、FactChecks、agent_pack、heartbeat、cron、automation、タスク番号、制作パック、台帳、作業ログを本文に書かない。
- 「この制作cronでは301を実行しない」「別工程で旧URLからの301を扱う」「辞書記事では整理する」など、作業工程の説明を本文に出さない。
- これらは内部ログ、Hub、台帳、QA記録にだけ残す。
- 公開本文では、サービス内容、料金、無料範囲、年齢制限、登録、決済、退会、安全面、注意点、公式リンクなど読者向け情報へ書き換える。
- 本文・見出し・表・FAQ・CTA周辺に内部運用語があればFAILとし、公開継続または301実行前に修正する。

全評価ページ共通 / 検索意図・上位傾向・共起語整理Gate（2026-05-17追記）:
- 公式情報と参照URL検証が終わった後、1-C記事制作パック前に `1-B2 検索意図・上位傾向・共起語整理` を行う。
- 整理するものは、読者の主要検索意図、上位記事でよく扱われる論点、自然に使えそうな共起語、使わない語、H2/H3・評価表・FAQ・リード文への反映案。
- 共起語は本文へ機械的に詰め込むノルマではない。読者理解を助ける範囲で自然に使う。
- 公式情報と矛盾する上位傾向、サービス内容と関係が薄い語、根拠不足の語は採用しない。
- 1-C制作パックには「自然使用候補」「使わない語」「構成への反映案」を分けて残す。
- 8高品質テストと9-A改善候補抽出では、このメモを見て「不足」「過剰」「不自然な詰め込み」「無関係語の混入」を確認する。

Task10本文修正・終了状態Gate（2026-05-17追加）:
- FAIL原因が本文、FAQ、冒頭構成にある場合、第一手はWordPress本文修正にする。
- Cocoon設定、page_type、テーマ設定、広告/PR表示設定などの設定側変更は補助手段。H1重複、表示崩れ、評価表欠落、本文順序崩れのリスクが出た時点で撤回し、本文修正ルートへ戻る。
- 設定側を触って失敗しただけで本文修正せずに終了しない。
- 内部作業文を公開本文から削除する。
- FAQ内の内部作業設問を削除し、必要なら読者向けFAQへ置き換える。例: 「旧記事から301してよいか」「この制作cronでは301を実行しない」「公開QAが通ったあと」は削除対象。
- 冒頭順を H1 → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2 に整える。
- 公開HTMLでH1重複、コード露出、内部作業語、評価表、公式リンク、canonical、noindexを再確認する。
- PASS後にだけ301可否へ進む。PASS前に旧URLから301しない。
- 1回のcronでは1記事だけ処理する。同じ失敗ルートを繰り返さない。
- 作業は必ず PASS / FAIL_REQUEUED / BLOCKED_HUB_AUTH / BLOCKED_WP_AUTH / BLOCKED_WP_WRITE / BLOCKED_LAYOUT_RISK / BLOCKED_MISSING_TARGET のいずれかで終了する。ローディングし続けない。

評価項目本文化・FAQ qa-box・装飾バランスGate（2026-05-17追加）:
- 評価スコア表の各項目は、本文内でH2またはH3見出しとして扱い、スコア理由、読者が確認すべき点、向いている人/注意点を書く。表だけで終わらせない。
- 評価項目名と本文見出し名は、完全一致または読者が同じ項目だと分かる名前にする。評価項目の説明が無い場合は本文ボリューム不足としてFAIL。
- 本文FAQは `<details class="qa-box"><summary>質問文</summary><div class="qa-answer">回答文</div></details>` を標準にする。
- FAQPage JSON-LDは `Schema & Structured Data for WP & AMP` 用に作成し、本文FAQと質問文・回答内容を一致させる。JSON-LDだけあり本文FAQが無い、または本文FAQがqa-boxでない場合はFAIL。
- FAQには、旧記事、301、公開QA、Hub、heartbeat、cron、Gate、PASS/FAILなど内部作業設問を入れない。
- 装飾は太字、黄色アンダー、赤太字、✅、⚠️、Cocoon系ボックス、リストをバランスよく使い分ける。
- `<li>` の先頭へ毎回✅/⚠️を付けない。リスト記号とアイコンの二重信号で読みづらい場合はFAIL。
- `information-box` / `warning-box` / `blank-box` などボックス自体が意味を持つ場合、原則として✅/⚠️を重ねない。必要な場合だけ最小限にする。
- ✅/⚠️だけを使う箇所、リストを使う箇所、ボックスを使う箇所を分ける。装飾不足も過剰装飾もFAIL。
- 既知の検出必須例: https://porn-fun.com/sites/fc2-live-adult-review/ は、評価項目本文見出し不足、qa-box FAQ不足、装飾バランス不備として訂正対象。

全評価ページ共通 / ✅・⚠️優先装飾Gate（2026-05-17追加）:
- 強み・注意点・向いている人・向いていない人を短く見せられる箇所では、ただの箇条書きより✅/⚠️の単独強調文を優先する。
- ✅は強み/向いている人/判断しやすい利点、⚠️は注意点/向いていない人/確認が必要な条件/制約に使う。
- 1文で伝わる強み/注意点は `<p>✅ ...</p>` / `<p>⚠️ ...</p>` のような単独文を優先する。
- 複数条件を並列整理するときは`<ul><li>`を使ってよいが、各`li`先頭へ毎回✅/⚠️を付けない。
- `information-box` / `warning-box` / `blank-box`などボックス自体が意味を持つ場合、ボックス内へ✅/⚠️を機械的に重ねない。
- 評価ページで✅/⚠️が0件のまま、強みや注意点をすべて普通の`li`やボックスだけで処理している場合は装飾不足としてFAIL。
- 既知の検出必須例: https://porn-fun.com/sites/fc2-live-adult-review/ は、qa-boxは改善済みだが✅/⚠️が0件のため訂正対象。

全サイト共通 / 1-C〜7制作完了→8高品質テスト引き渡しGate（2026-05-17追加）:
- 1-C〜7で記事を公開したら、公開URLを作っただけで終わらず、同じarticle_keyで task_code=8 / use_status=public_qa_handoff / check_status=ready / status=active のReferencesを必ず作る。
- 8高品質テストは、public_qa_handoffだけでなく、use_status=published_directory_article / task_code=7 / 公開済み新記事URLも横断して確認する。
- 同じarticle_keyにtask8 PASSまたはtask8 high-quality test完了記録が無い公開済み記事を「未処理対象なし」と扱わない。
- 7の公開HTML QA PASS、Directory Core入力PASS、published_directory_articleがあるのに8のPASSが無い場合は、明示ハンドオフ漏れとして8対象にする。
- Hub認証不備時は対象なし/PASS/完了と誤判定せず、BLOCKED_HUB_AUTHとして終了する。
- 既知の補正例: https://porn-fun.com/sites/hey-douga-review/ は1-C〜7で公開済みだが、8用の明示的ハンドオフが弱かったため、public_qa_handoffを追加して8対象に戻した。

cron標準 / サイト別1スレッド運用（2026-05-17追加）:
- オートポスト支社の通常運用はcron標準。heartbeatは例外運用に限る。
- 1サイトまたは1セットにつき、関連cronを依頼・管理する起動スレッドは1つだけにする。
- 各タスクごとの新スレッド立ち上げ文は不要。各タスク欄のコピー文は、そのサイト別cron統括スレッド内で使うcron作成依頼文として扱う。
- automation名は `【サイト名＋評価スコアページ種別】タスク順番 cron 内容` を標準にする。
- 1回1記事制限、最大処理件数、対象なし終了、BLOCKED_*終了条件はcron本文内に書く。
- Hub正本、Work Queue、References、FactChecks、台帳で状態管理する。
- heartbeatは、ユーザーと同じスレッドで短時間だけ追跡する場合、手動確認が必要な一時作業、緊急修正、外部AI/改善担当との会話型ハンドオフが必要な場合だけ使う。

cron個別作成Gate:
- サイト別cron統括スレッド起動文を貼っただけではcronを作成しない。
- 統括スレッド起動文では、Hub、agent_pack、Work Queue、References、FactChecks、台帳、既存automationを確認し、既存cronと未作成cronを整理して報告するだけにする。
- cron作成は、ユーザーが各タスク欄のcron作成依頼文を個別に貼った時だけ行う。
- 1回のcron作成依頼文で作るautomationは1つだけにする。
- ユーザーが「全cronをまとめて作って」と明示しない限り、複数cronを一括作成しない。

評価スコアページ用cron命名Gate:
このcronは、まとめページ、キラーページ、通常記事、速報記事ではなく、評価スコア表を持つ辞書型・レビュー型ページ専用として扱う。
automation名には必ず「評価スコアページ」を入れる。
例:
- 【AIfunIO評価スコアページ】0-A cron 候補収集
- 【Nightlife夜遊び店舗評価スコアページ】0-B/1-A/1-B cron 候補精査・参照URL整理・URL検証
- 【Nightlifeホテル評価スコアページ】8 cron 高品質テスト
- 【porn-fun単体サービス評価スコアページ移行】11 cron 301実行・リダイレクト確認
まとめ/ランキング/比較/通常/速報記事用のautomationは別命名・別テンプレートにする。

Nightlife夜遊び店舗用 訂正cron

automation名: 【Nightlife夜遊び店舗評価スコアページ】10 cron 公開後訂正管理

Nightlife夜遊び店舗用 訂正cron 新スレ起動文

コピー

# 【Nightlife夜遊び店舗評価スコアページ】10 cron 公開後訂正管理 新スレ起動文

このスレッドは、以下のautomationだけを作成・運用する専用スレッドです。
1スレッドにheartbeatは1つだけなので、他のcron用途を混ぜないでください。
cron automationの場合も、このサイト別cron統括スレッド内で、このcron作成依頼として扱ってください。

作成するautomation名:
【Nightlife夜遊び店舗評価スコアページ】10 cron 公開後訂正管理

対象:
Nightlife / 夜遊び店舗 / nightlife-directory-review-ja

区分:
cron

起動時間:
JST 21:30

頻度:
1日1回 / FAILがある場合

目的:
FAILキューを1記事ずつ修正する。

最初に確認するもの:
- Main Hub: https://hub.goudou-358.jp
- 対象レポート: https://report.goudou-358.jp/nightlife-store-automation-request-templates-20260517/
- CODE-YUKI作業室: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI
- CODE-YUKI引継ぎ控え: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI\handoffs\2026-05-17_global_opening_gate_external_hb_handoff.md
- 外部HB起動文控え: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI\handoffs\2026-05-17_external_improvement_hb_startup_prompt.md
- オートポスト支社共有: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common
- branch_common保険控え: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common\manuals\first-development-source-copies\2026-05-17-global-opening-improvement-gate\global-opening-improvement-handoff.md
- Nightlife正本: Main Hub / workflow_id=nightlife-directory-review-ja
- Nightlife共通台帳: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common\ledgers\directory-core\directory-article-input-ledger.md
- Nightlife辞書セット共通台帳: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common\ledgers\directory-core\directory-set-template-registry.md
- Nightlifeローカル保険控え: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common\manuals\first-development-source-copies
- Nightlife専用サイト部フォルダが未分離の場合は、Main Hub正本とCODE-YUKI作業室を優先する。

必ず守ること:
- automation作成時の名前は、上記のautomation名をそのまま使う。
- Main Hubを正本にし、agent_pack / Work Queue / References / FactChecks / Rules / Manualsを確認してから動く。
- ローカルPC内の storage/data/358-hub.sqlite が無いだけで停止しない。
- 認証情報、APIキー、パスワード、トークン、WordPress REST認証情報の中身を読まない・表示しない。
- 通常の.mdログ、記事本文、キュー、投稿結果の更新ではapply_patchを使わない。
- GATE失敗、未承認、危険操作、認証情報、権限変更、ファイル削除/移動/上書き、本番コード編集は停止して確認する。
- Hubが401/403/invalid token等で読めない場合は、対象なし扱いにしない。`BLOCKED_HUB_AUTH / Hub認証不備 / 正本未確認 / 記事修正なし` と報告する。

全記事共通Gate:
- 冒頭構成は H1タイトル → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2。
- 公式テキストリンクは、アフィリエイトリンクがある場合はアフィリエイトリンク、無い場合は公式リンク。
- 公式テキストリンクはPC表示で本文右側または右寄せ。
- 参照例: https://invest358.com/ja/thinkmarkets-review/
- H1重複、コード露出、公式で要確認などの仮置き、言語不一致、装飾不足はFAIL。

この内容でautomationを作成してください。
作成後は、automation名、区分、起動時間、対象、初回実行で確認するHub項目を報告してください。

全評価ページ共通 / task10・8・9-A/9-B 訂正対象取得Gate（2026-05-17追記）:
- `task10/FAILキュー` という名前だけを見て0件判定しない。
- Main HubのWork Queue / Tasks、References、FactChecks、9-A/9-Bのreturned状態を横断して確認する。
- Referencesの `use_status=correction_queue`、`public_qa_handoff`、`quality_fail`、`correction_required`、または `check_status=ready/fail/failed` を訂正対象として見る。
- FactChecksの `fact_check_id`、`check_status`、`notes` に `fail` / `FAIL` / `Gate failed` / `Gate失敗` / `要修正` があるものを拾う。
- workflow共通の `article_key` だけに限定せず、記事別key、slug別key、移行記事keyも同じsite/workflow/domain内なら拾う。
- agent_packに他サイトのFAILが混在して見える場合は、対象site / workflow / domain / article_typeで絞り込み、別サイトのFAILを自分の訂正対象にしない。
- 上記を確認せずに「FAILキュー0件」「対象なし」「記事修正なし」「301対応なし」「PASS/完了」と報告しない。
- Hubが401/403/invalid token/token expired/timeout/DNS/network errorで読めない場合は、対象なし扱いにせず `BLOCKED_HUB_AUTH / Hub認証不備 / 正本未確認 / 記事修正なし` と報告する。

全評価ページ共通 / 公開本文境界Gate（2026-05-17追記）:
- 公開本文には、読者のサービス判断に必要な情報だけを書く。
- 301、リダイレクト、旧URL、旧記事、新辞書記事、移行、公開QA、Gate、PASS、FAIL、Hub、Work Queue、References、FactChecks、agent_pack、heartbeat、cron、automation、タスク番号、制作パック、台帳、作業ログを本文に書かない。
- 「この制作cronでは301を実行しない」「別工程で旧URLからの301を扱う」「辞書記事では整理する」など、作業工程の説明を本文に出さない。
- これらは内部ログ、Hub、台帳、QA記録にだけ残す。
- 公開本文では、サービス内容、料金、無料範囲、年齢制限、登録、決済、退会、安全面、注意点、公式リンクなど読者向け情報へ書き換える。
- 本文・見出し・表・FAQ・CTA周辺に内部運用語があればFAILとし、公開継続または301実行前に修正する。

全評価ページ共通 / 検索意図・上位傾向・共起語整理Gate（2026-05-17追記）:
- 公式情報と参照URL検証が終わった後、1-C記事制作パック前に `1-B2 検索意図・上位傾向・共起語整理` を行う。
- 整理するものは、読者の主要検索意図、上位記事でよく扱われる論点、自然に使えそうな共起語、使わない語、H2/H3・評価表・FAQ・リード文への反映案。
- 共起語は本文へ機械的に詰め込むノルマではない。読者理解を助ける範囲で自然に使う。
- 公式情報と矛盾する上位傾向、サービス内容と関係が薄い語、根拠不足の語は採用しない。
- 1-C制作パックには「自然使用候補」「使わない語」「構成への反映案」を分けて残す。
- 8高品質テストと9-A改善候補抽出では、このメモを見て「不足」「過剰」「不自然な詰め込み」「無関係語の混入」を確認する。

Task10本文修正・終了状態Gate（2026-05-17追加）:
- FAIL原因が本文、FAQ、冒頭構成にある場合、第一手はWordPress本文修正にする。
- Cocoon設定、page_type、テーマ設定、広告/PR表示設定などの設定側変更は補助手段。H1重複、表示崩れ、評価表欠落、本文順序崩れのリスクが出た時点で撤回し、本文修正ルートへ戻る。
- 設定側を触って失敗しただけで本文修正せずに終了しない。
- 内部作業文を公開本文から削除する。
- FAQ内の内部作業設問を削除し、必要なら読者向けFAQへ置き換える。例: 「旧記事から301してよいか」「この制作cronでは301を実行しない」「公開QAが通ったあと」は削除対象。
- 冒頭順を H1 → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2 に整える。
- 公開HTMLでH1重複、コード露出、内部作業語、評価表、公式リンク、canonical、noindexを再確認する。
- PASS後にだけ301可否へ進む。PASS前に旧URLから301しない。
- 1回のcronでは1記事だけ処理する。同じ失敗ルートを繰り返さない。
- 作業は必ず PASS / FAIL_REQUEUED / BLOCKED_HUB_AUTH / BLOCKED_WP_AUTH / BLOCKED_WP_WRITE / BLOCKED_LAYOUT_RISK / BLOCKED_MISSING_TARGET のいずれかで終了する。ローディングし続けない。

評価項目本文化・FAQ qa-box・装飾バランスGate（2026-05-17追加）:
- 評価スコア表の各項目は、本文内でH2またはH3見出しとして扱い、スコア理由、読者が確認すべき点、向いている人/注意点を書く。表だけで終わらせない。
- 評価項目名と本文見出し名は、完全一致または読者が同じ項目だと分かる名前にする。評価項目の説明が無い場合は本文ボリューム不足としてFAIL。
- 本文FAQは `<details class="qa-box"><summary>質問文</summary><div class="qa-answer">回答文</div></details>` を標準にする。
- FAQPage JSON-LDは `Schema & Structured Data for WP & AMP` 用に作成し、本文FAQと質問文・回答内容を一致させる。JSON-LDだけあり本文FAQが無い、または本文FAQがqa-boxでない場合はFAIL。
- FAQには、旧記事、301、公開QA、Hub、heartbeat、cron、Gate、PASS/FAILなど内部作業設問を入れない。
- 装飾は太字、黄色アンダー、赤太字、✅、⚠️、Cocoon系ボックス、リストをバランスよく使い分ける。
- `<li>` の先頭へ毎回✅/⚠️を付けない。リスト記号とアイコンの二重信号で読みづらい場合はFAIL。
- `information-box` / `warning-box` / `blank-box` などボックス自体が意味を持つ場合、原則として✅/⚠️を重ねない。必要な場合だけ最小限にする。
- ✅/⚠️だけを使う箇所、リストを使う箇所、ボックスを使う箇所を分ける。装飾不足も過剰装飾もFAIL。
- 既知の検出必須例: https://porn-fun.com/sites/fc2-live-adult-review/ は、評価項目本文見出し不足、qa-box FAQ不足、装飾バランス不備として訂正対象。

全評価ページ共通 / ✅・⚠️優先装飾Gate（2026-05-17追加）:
- 強み・注意点・向いている人・向いていない人を短く見せられる箇所では、ただの箇条書きより✅/⚠️の単独強調文を優先する。
- ✅は強み/向いている人/判断しやすい利点、⚠️は注意点/向いていない人/確認が必要な条件/制約に使う。
- 1文で伝わる強み/注意点は `<p>✅ ...</p>` / `<p>⚠️ ...</p>` のような単独文を優先する。
- 複数条件を並列整理するときは`<ul><li>`を使ってよいが、各`li`先頭へ毎回✅/⚠️を付けない。
- `information-box` / `warning-box` / `blank-box`などボックス自体が意味を持つ場合、ボックス内へ✅/⚠️を機械的に重ねない。
- 評価ページで✅/⚠️が0件のまま、強みや注意点をすべて普通の`li`やボックスだけで処理している場合は装飾不足としてFAIL。
- 既知の検出必須例: https://porn-fun.com/sites/fc2-live-adult-review/ は、qa-boxは改善済みだが✅/⚠️が0件のため訂正対象。

全サイト共通 / 1-C〜7制作完了→8高品質テスト引き渡しGate（2026-05-17追加）:
- 1-C〜7で記事を公開したら、公開URLを作っただけで終わらず、同じarticle_keyで task_code=8 / use_status=public_qa_handoff / check_status=ready / status=active のReferencesを必ず作る。
- 8高品質テストは、public_qa_handoffだけでなく、use_status=published_directory_article / task_code=7 / 公開済み新記事URLも横断して確認する。
- 同じarticle_keyにtask8 PASSまたはtask8 high-quality test完了記録が無い公開済み記事を「未処理対象なし」と扱わない。
- 7の公開HTML QA PASS、Directory Core入力PASS、published_directory_articleがあるのに8のPASSが無い場合は、明示ハンドオフ漏れとして8対象にする。
- Hub認証不備時は対象なし/PASS/完了と誤判定せず、BLOCKED_HUB_AUTHとして終了する。
- 既知の補正例: https://porn-fun.com/sites/hey-douga-review/ は1-C〜7で公開済みだが、8用の明示的ハンドオフが弱かったため、public_qa_handoffを追加して8対象に戻した。

cron標準 / サイト別1スレッド運用（2026-05-17追加）:
- オートポスト支社の通常運用はcron標準。heartbeatは例外運用に限る。
- 1サイトまたは1セットにつき、関連cronを依頼・管理する起動スレッドは1つだけにする。
- 各タスクごとの新スレッド立ち上げ文は不要。各タスク欄のコピー文は、そのサイト別cron統括スレッド内で使うcron作成依頼文として扱う。
- automation名は `【サイト名＋評価スコアページ種別】タスク順番 cron 内容` を標準にする。
- 1回1記事制限、最大処理件数、対象なし終了、BLOCKED_*終了条件はcron本文内に書く。
- Hub正本、Work Queue、References、FactChecks、台帳で状態管理する。
- heartbeatは、ユーザーと同じスレッドで短時間だけ追跡する場合、手動確認が必要な一時作業、緊急修正、外部AI/改善担当との会話型ハンドオフが必要な場合だけ使う。

cron個別作成Gate:
- サイト別cron統括スレッド起動文を貼っただけではcronを作成しない。
- 統括スレッド起動文では、Hub、agent_pack、Work Queue、References、FactChecks、台帳、既存automationを確認し、既存cronと未作成cronを整理して報告するだけにする。
- cron作成は、ユーザーが各タスク欄のcron作成依頼文を個別に貼った時だけ行う。
- 1回のcron作成依頼文で作るautomationは1つだけにする。
- ユーザーが「全cronをまとめて作って」と明示しない限り、複数cronを一括作成しない。

評価スコアページ用cron命名Gate:
このcronは、まとめページ、キラーページ、通常記事、速報記事ではなく、評価スコア表を持つ辞書型・レビュー型ページ専用として扱う。
automation名には必ず「評価スコアページ」を入れる。
例:
- 【AIfunIO評価スコアページ】0-A cron 候補収集
- 【Nightlife夜遊び店舗評価スコアページ】0-B/1-A/1-B cron 候補精査・参照URL整理・URL検証
- 【Nightlifeホテル評価スコアページ】8 cron 高品質テスト
- 【porn-fun単体サービス評価スコアページ移行】11 cron 301実行・リダイレクト確認
まとめ/ランキング/比較/通常/速報記事用のautomationは別命名・別テンプレートにする。

Nightlife夜遊び店舗用 訂正cron automation作成依頼文

コピー

Nightlife夜遊び店舗用 訂正cron automationを作成してください。

automation名: 【Nightlife夜遊び店舗評価スコアページ】10 cron 公開後訂正管理
名前は必ずこの形で登録してください。人間がautomation一覧を見た時に、サイト名・タスク順番・cron/heartbeat・内容が分かるようにします。

対象: Nightlife / 夜遊び店舗 / nightlife-directory-review-ja
区分: cron
起動時間: JST 21:30
頻度: 1日1回 / FAILがある場合

目的:
FAILキューを1記事ずつ修正する。

共通ルール:
- Main Hubを正本にする。Standby Hubはreadonly、Googleスプレッドシート/Apps Script/Google承認には戻らない。
- ローカルPC内の storage/data/358-hub.sqlite が無いだけで止まらない。Main Hub Web、agent_pack、Work Queue、References、FactChecks、hub_table_upsert相当の利用可能手段を優先する。
- 認証情報、APIキー、パスワード、トークン、WordPress REST認証情報の中身は表示しない。
- 通常の.mdログ、記事本文、キュー、投稿結果の更新ではapply_patchを使わない。承認が出にくい安全な書き込み手段を使う。
- PHP/JS/CSS等の本番コード編集、ファイル削除、移動、上書き、外部公開先の新規追加、認証情報、権限変更は停止して確認する。
- 公開投稿そのものは停止条件ではない。止めるのは未承認、未検査、危険操作、GATE失敗の場合だけ。
- 0-A/0-Bなどの棚処理は複数候補を扱ってよい。1回1記事制限は制作cron、高品質テストcron、訂正cron、改善担当ハンドオフcronに適用する。
- automation名は `【サイト名＋評価スコアページ種別】タスク順番 cron 内容` の形で登録する。
- 各cronを作る時は、対象レポート記事の各項目にある新スレ起動文を先に貼り、専用スレッドとして状態復元してからautomationを作成する。
- Main Hubが401/403/invalid token/token expired/timeout/DNS/network error等で読めない場合、その回は対象なし、FAILなし、PASS、完了と判断しない。必ず `BLOCKED_HUB_AUTH / Hub認証不備 / 正本未確認 / 記事修正なし` と報告する。
- Hub正本を読めない状態で、公開、修正、301、Hub更新、PASS/FAIL確定を行わない。

全記事共通Gate:
- 全評価ページ共通で、冒頭はH1タイトル → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2の順にする。
- 公式テキストリンクは、アフィリエイトリンクがある場合はアフィリエイトリンク、無い場合は公式リンクにする。
- 公式テキストリンクはPC表示で本文右側または右寄せに置く。読者が本文導線として見つけられる位置にする。
- 参照例は https://invest358.com/ja/thinkmarkets-review/ とする。完全コピーではなく、冒頭構成と導線を継承する。
- H1重複、H1へのSEOタイトル混入、評価表の順序崩れ、公式リンク漏れ、コード露出、言語不一致はFAIL。
- 日本語ページは常体を基本にする。ただし偉そうにせず、落ち着いた説明文にする。対象ページの言語に合わせて基本表/補足情報も同じ言語で書く。
- 装飾は既存良質記事を継承する。太字、太字+黄色アンダー、赤太字、✅、⚠️、Cocoon系ボックスを必要箇所へ自然に入れる。
- 9-Aで文章QA/共起語改善候補を抽出し、9-Bで改善担当へ渡し、10で返却反映と硬いGate確認を行う。
- improvement_status、improvement_owner、improvement_lockを記録する。handed_offかつlock中の本文を返却前に主観リライトしない。

サイト別Gate:
- Nightlife夜遊び店舗は、H1は店舗/サービス名のみ。SEOタイトルは「店舗名 + 評価・評判・レビュー」系KWを含める。
- 最寄り駅、営業時間、料金目安、予約/問い合わせ、決済方法、対応エリアは公式または補助根拠を調べて書く。
- 公式で要確認などの空欄逃げを本文/表/Directory Core値に残したらFAIL。断定できない場合は根拠と不確実性を整理する。

やること:
- FAILキューから1回1記事だけ修正する。
- 修正後は公開HTMLで再確認し、PASS/FAILと次工程をMain Hubへ記録する。

止める条件:
- GATE失敗、未承認サイト、認証情報、権限変更、ファイル削除/移動/上書き、本番コード編集、外部公開先の新規追加。
- 公開投稿そのものは停止条件にしない。

出力:
修正内容、再確認結果、PASS/FAILを報告する。

全評価ページ共通 / task10・8・9-A/9-B 訂正対象取得Gate（2026-05-17追記）:
- `task10/FAILキュー` という名前だけを見て0件判定しない。
- Main HubのWork Queue / Tasks、References、FactChecks、9-A/9-Bのreturned状態を横断して確認する。
- Referencesの `use_status=correction_queue`、`public_qa_handoff`、`quality_fail`、`correction_required`、または `check_status=ready/fail/failed` を訂正対象として見る。
- FactChecksの `fact_check_id`、`check_status`、`notes` に `fail` / `FAIL` / `Gate failed` / `Gate失敗` / `要修正` があるものを拾う。
- workflow共通の `article_key` だけに限定せず、記事別key、slug別key、移行記事keyも同じsite/workflow/domain内なら拾う。
- agent_packに他サイトのFAILが混在して見える場合は、対象site / workflow / domain / article_typeで絞り込み、別サイトのFAILを自分の訂正対象にしない。
- 上記を確認せずに「FAILキュー0件」「対象なし」「記事修正なし」「301対応なし」「PASS/完了」と報告しない。
- Hubが401/403/invalid token/token expired/timeout/DNS/network errorで読めない場合は、対象なし扱いにせず `BLOCKED_HUB_AUTH / Hub認証不備 / 正本未確認 / 記事修正なし` と報告する。

全評価ページ共通 / 公開本文境界Gate（2026-05-17追記）:
- 公開本文には、読者のサービス判断に必要な情報だけを書く。
- 301、リダイレクト、旧URL、旧記事、新辞書記事、移行、公開QA、Gate、PASS、FAIL、Hub、Work Queue、References、FactChecks、agent_pack、heartbeat、cron、automation、タスク番号、制作パック、台帳、作業ログを本文に書かない。
- 「この制作cronでは301を実行しない」「別工程で旧URLからの301を扱う」「辞書記事では整理する」など、作業工程の説明を本文に出さない。
- これらは内部ログ、Hub、台帳、QA記録にだけ残す。
- 公開本文では、サービス内容、料金、無料範囲、年齢制限、登録、決済、退会、安全面、注意点、公式リンクなど読者向け情報へ書き換える。
- 本文・見出し・表・FAQ・CTA周辺に内部運用語があればFAILとし、公開継続または301実行前に修正する。

全評価ページ共通 / 検索意図・上位傾向・共起語整理Gate（2026-05-17追記）:
- 公式情報と参照URL検証が終わった後、1-C記事制作パック前に `1-B2 検索意図・上位傾向・共起語整理` を行う。
- 整理するものは、読者の主要検索意図、上位記事でよく扱われる論点、自然に使えそうな共起語、使わない語、H2/H3・評価表・FAQ・リード文への反映案。
- 共起語は本文へ機械的に詰め込むノルマではない。読者理解を助ける範囲で自然に使う。
- 公式情報と矛盾する上位傾向、サービス内容と関係が薄い語、根拠不足の語は採用しない。
- 1-C制作パックには「自然使用候補」「使わない語」「構成への反映案」を分けて残す。
- 8高品質テストと9-A改善候補抽出では、このメモを見て「不足」「過剰」「不自然な詰め込み」「無関係語の混入」を確認する。

Task10本文修正・終了状態Gate（2026-05-17追加）:
- FAIL原因が本文、FAQ、冒頭構成にある場合、第一手はWordPress本文修正にする。
- Cocoon設定、page_type、テーマ設定、広告/PR表示設定などの設定側変更は補助手段。H1重複、表示崩れ、評価表欠落、本文順序崩れのリスクが出た時点で撤回し、本文修正ルートへ戻る。
- 設定側を触って失敗しただけで本文修正せずに終了しない。
- 内部作業文を公開本文から削除する。
- FAQ内の内部作業設問を削除し、必要なら読者向けFAQへ置き換える。例: 「旧記事から301してよいか」「この制作cronでは301を実行しない」「公開QAが通ったあと」は削除対象。
- 冒頭順を H1 → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2 に整える。
- 公開HTMLでH1重複、コード露出、内部作業語、評価表、公式リンク、canonical、noindexを再確認する。
- PASS後にだけ301可否へ進む。PASS前に旧URLから301しない。
- 1回のcronでは1記事だけ処理する。同じ失敗ルートを繰り返さない。
- 作業は必ず PASS / FAIL_REQUEUED / BLOCKED_HUB_AUTH / BLOCKED_WP_AUTH / BLOCKED_WP_WRITE / BLOCKED_LAYOUT_RISK / BLOCKED_MISSING_TARGET のいずれかで終了する。ローディングし続けない。

評価項目本文化・FAQ qa-box・装飾バランスGate（2026-05-17追加）:
- 評価スコア表の各項目は、本文内でH2またはH3見出しとして扱い、スコア理由、読者が確認すべき点、向いている人/注意点を書く。表だけで終わらせない。
- 評価項目名と本文見出し名は、完全一致または読者が同じ項目だと分かる名前にする。評価項目の説明が無い場合は本文ボリューム不足としてFAIL。
- 本文FAQは `<details class="qa-box"><summary>質問文</summary><div class="qa-answer">回答文</div></details>` を標準にする。
- FAQPage JSON-LDは `Schema & Structured Data for WP & AMP` 用に作成し、本文FAQと質問文・回答内容を一致させる。JSON-LDだけあり本文FAQが無い、または本文FAQがqa-boxでない場合はFAIL。
- FAQには、旧記事、301、公開QA、Hub、heartbeat、cron、Gate、PASS/FAILなど内部作業設問を入れない。
- 装飾は太字、黄色アンダー、赤太字、✅、⚠️、Cocoon系ボックス、リストをバランスよく使い分ける。
- `<li>` の先頭へ毎回✅/⚠️を付けない。リスト記号とアイコンの二重信号で読みづらい場合はFAIL。
- `information-box` / `warning-box` / `blank-box` などボックス自体が意味を持つ場合、原則として✅/⚠️を重ねない。必要な場合だけ最小限にする。
- ✅/⚠️だけを使う箇所、リストを使う箇所、ボックスを使う箇所を分ける。装飾不足も過剰装飾もFAIL。
- 既知の検出必須例: https://porn-fun.com/sites/fc2-live-adult-review/ は、評価項目本文見出し不足、qa-box FAQ不足、装飾バランス不備として訂正対象。

全評価ページ共通 / ✅・⚠️優先装飾Gate（2026-05-17追加）:
- 強み・注意点・向いている人・向いていない人を短く見せられる箇所では、ただの箇条書きより✅/⚠️の単独強調文を優先する。
- ✅は強み/向いている人/判断しやすい利点、⚠️は注意点/向いていない人/確認が必要な条件/制約に使う。
- 1文で伝わる強み/注意点は `<p>✅ ...</p>` / `<p>⚠️ ...</p>` のような単独文を優先する。
- 複数条件を並列整理するときは`<ul><li>`を使ってよいが、各`li`先頭へ毎回✅/⚠️を付けない。
- `information-box` / `warning-box` / `blank-box`などボックス自体が意味を持つ場合、ボックス内へ✅/⚠️を機械的に重ねない。
- 評価ページで✅/⚠️が0件のまま、強みや注意点をすべて普通の`li`やボックスだけで処理している場合は装飾不足としてFAIL。
- 既知の検出必須例: https://porn-fun.com/sites/fc2-live-adult-review/ は、qa-boxは改善済みだが✅/⚠️が0件のため訂正対象。

全サイト共通 / 1-C〜7制作完了→8高品質テスト引き渡しGate（2026-05-17追加）:
- 1-C〜7で記事を公開したら、公開URLを作っただけで終わらず、同じarticle_keyで task_code=8 / use_status=public_qa_handoff / check_status=ready / status=active のReferencesを必ず作る。
- 8高品質テストは、public_qa_handoffだけでなく、use_status=published_directory_article / task_code=7 / 公開済み新記事URLも横断して確認する。
- 同じarticle_keyにtask8 PASSまたはtask8 high-quality test完了記録が無い公開済み記事を「未処理対象なし」と扱わない。
- 7の公開HTML QA PASS、Directory Core入力PASS、published_directory_articleがあるのに8のPASSが無い場合は、明示ハンドオフ漏れとして8対象にする。
- Hub認証不備時は対象なし/PASS/完了と誤判定せず、BLOCKED_HUB_AUTHとして終了する。
- 既知の補正例: https://porn-fun.com/sites/hey-douga-review/ は1-C〜7で公開済みだが、8用の明示的ハンドオフが弱かったため、public_qa_handoffを追加して8対象に戻した。

cron標準 / サイト別1スレッド運用（2026-05-17追加）:
- オートポスト支社の通常運用はcron標準。heartbeatは例外運用に限る。
- 1サイトまたは1セットにつき、関連cronを依頼・管理する起動スレッドは1つだけにする。
- 各タスクごとの新スレッド立ち上げ文は不要。各タスク欄のコピー文は、そのサイト別cron統括スレッド内で使うcron作成依頼文として扱う。
- automation名は `【サイト名＋評価スコアページ種別】タスク順番 cron 内容` を標準にする。
- 1回1記事制限、最大処理件数、対象なし終了、BLOCKED_*終了条件はcron本文内に書く。
- Hub正本、Work Queue、References、FactChecks、台帳で状態管理する。
- heartbeatは、ユーザーと同じスレッドで短時間だけ追跡する場合、手動確認が必要な一時作業、緊急修正、外部AI/改善担当との会話型ハンドオフが必要な場合だけ使う。

cron個別作成Gate:
- サイト別cron統括スレッド起動文を貼っただけではcronを作成しない。
- 統括スレッド起動文では、Hub、agent_pack、Work Queue、References、FactChecks、台帳、既存automationを確認し、既存cronと未作成cronを整理して報告するだけにする。
- cron作成は、ユーザーが各タスク欄のcron作成依頼文を個別に貼った時だけ行う。
- 1回のcron作成依頼文で作るautomationは1つだけにする。
- ユーザーが「全cronをまとめて作って」と明示しない限り、複数cronを一括作成しない。

評価スコアページ用cron命名Gate:
このcronは、まとめページ、キラーページ、通常記事、速報記事ではなく、評価スコア表を持つ辞書型・レビュー型ページ専用として扱う。
automation名には必ず「評価スコアページ」を入れる。
例:
- 【AIfunIO評価スコアページ】0-A cron 候補収集
- 【Nightlife夜遊び店舗評価スコアページ】0-B/1-A/1-B cron 候補精査・参照URL整理・URL検証
- 【Nightlifeホテル評価スコアページ】8 cron 高品質テスト
- 【porn-fun単体サービス評価スコアページ移行】11 cron 301実行・リダイレクト確認
まとめ/ランキング/比較/通常/速報記事用のautomationは別命名・別テンプレートにする。

Nightlife夜遊び店舗用 改善担当ハンドオフcron

automation名: 【Nightlife夜遊び店舗評価スコアページ】9-A/9-B/10 cron 改善担当ハンドオフ

Nightlife夜遊び店舗用 改善担当ハンドオフcron 新スレ起動文

コピー

# 【Nightlife夜遊び店舗評価スコアページ】9-A/9-B/10 cron 改善担当ハンドオフ 新スレ起動文

このスレッドは、以下のautomationだけを作成・運用する専用スレッドです。
1スレッドにheartbeatは1つだけなので、他のcron用途を混ぜないでください。
cron automationの場合も、このサイト別cron統括スレッド内で、このcron作成依頼として扱ってください。

作成するautomation名:
【Nightlife夜遊び店舗評価スコアページ】9-A/9-B/10 cron 改善担当ハンドオフ

対象:
Nightlife / 夜遊び店舗 / nightlife-directory-review-ja

区分:
cron

起動時間:
JST 23:10

頻度:
1日1回

目的:
9-A/9-B/10の文章改善ハンドオフを処理する。

最初に確認するもの:
- Main Hub: https://hub.goudou-358.jp
- 対象レポート: https://report.goudou-358.jp/nightlife-store-automation-request-templates-20260517/
- CODE-YUKI作業室: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI
- CODE-YUKI引継ぎ控え: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI\handoffs\2026-05-17_global_opening_gate_external_hb_handoff.md
- 外部HB起動文控え: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI\handoffs\2026-05-17_external_improvement_hb_startup_prompt.md
- オートポスト支社共有: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common
- branch_common保険控え: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common\manuals\first-development-source-copies\2026-05-17-global-opening-improvement-gate\global-opening-improvement-handoff.md
- Nightlife正本: Main Hub / workflow_id=nightlife-directory-review-ja
- Nightlife共通台帳: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common\ledgers\directory-core\directory-article-input-ledger.md
- Nightlife辞書セット共通台帳: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common\ledgers\directory-core\directory-set-template-registry.md
- Nightlifeローカル保険控え: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common\manuals\first-development-source-copies
- Nightlife専用サイト部フォルダが未分離の場合は、Main Hub正本とCODE-YUKI作業室を優先する。

必ず守ること:
- automation作成時の名前は、上記のautomation名をそのまま使う。
- Main Hubを正本にし、agent_pack / Work Queue / References / FactChecks / Rules / Manualsを確認してから動く。
- ローカルPC内の storage/data/358-hub.sqlite が無いだけで停止しない。
- 認証情報、APIキー、パスワード、トークン、WordPress REST認証情報の中身を読まない・表示しない。
- 通常の.mdログ、記事本文、キュー、投稿結果の更新ではapply_patchを使わない。
- GATE失敗、未承認、危険操作、認証情報、権限変更、ファイル削除/移動/上書き、本番コード編集は停止して確認する。
- Hubが401/403/invalid token等で読めない場合は、対象なし扱いにしない。`BLOCKED_HUB_AUTH / Hub認証不備 / 正本未確認 / 記事修正なし` と報告する。

全記事共通Gate:
- 冒頭構成は H1タイトル → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2。
- 公式テキストリンクは、アフィリエイトリンクがある場合はアフィリエイトリンク、無い場合は公式リンク。
- 公式テキストリンクはPC表示で本文右側または右寄せ。
- 参照例: https://invest358.com/ja/thinkmarkets-review/
- H1重複、コード露出、公式で要確認などの仮置き、言語不一致、装飾不足はFAIL。

この内容でautomationを作成してください。
作成後は、automation名、区分、起動時間、対象、初回実行で確認するHub項目を報告してください。

全評価ページ共通 / task10・8・9-A/9-B 訂正対象取得Gate（2026-05-17追記）:
- `task10/FAILキュー` という名前だけを見て0件判定しない。
- Main HubのWork Queue / Tasks、References、FactChecks、9-A/9-Bのreturned状態を横断して確認する。
- Referencesの `use_status=correction_queue`、`public_qa_handoff`、`quality_fail`、`correction_required`、または `check_status=ready/fail/failed` を訂正対象として見る。
- FactChecksの `fact_check_id`、`check_status`、`notes` に `fail` / `FAIL` / `Gate failed` / `Gate失敗` / `要修正` があるものを拾う。
- workflow共通の `article_key` だけに限定せず、記事別key、slug別key、移行記事keyも同じsite/workflow/domain内なら拾う。
- agent_packに他サイトのFAILが混在して見える場合は、対象site / workflow / domain / article_typeで絞り込み、別サイトのFAILを自分の訂正対象にしない。
- 上記を確認せずに「FAILキュー0件」「対象なし」「記事修正なし」「301対応なし」「PASS/完了」と報告しない。
- Hubが401/403/invalid token/token expired/timeout/DNS/network errorで読めない場合は、対象なし扱いにせず `BLOCKED_HUB_AUTH / Hub認証不備 / 正本未確認 / 記事修正なし` と報告する。

全評価ページ共通 / 公開本文境界Gate（2026-05-17追記）:
- 公開本文には、読者のサービス判断に必要な情報だけを書く。
- 301、リダイレクト、旧URL、旧記事、新辞書記事、移行、公開QA、Gate、PASS、FAIL、Hub、Work Queue、References、FactChecks、agent_pack、heartbeat、cron、automation、タスク番号、制作パック、台帳、作業ログを本文に書かない。
- 「この制作cronでは301を実行しない」「別工程で旧URLからの301を扱う」「辞書記事では整理する」など、作業工程の説明を本文に出さない。
- これらは内部ログ、Hub、台帳、QA記録にだけ残す。
- 公開本文では、サービス内容、料金、無料範囲、年齢制限、登録、決済、退会、安全面、注意点、公式リンクなど読者向け情報へ書き換える。
- 本文・見出し・表・FAQ・CTA周辺に内部運用語があればFAILとし、公開継続または301実行前に修正する。

全評価ページ共通 / 検索意図・上位傾向・共起語整理Gate（2026-05-17追記）:
- 公式情報と参照URL検証が終わった後、1-C記事制作パック前に `1-B2 検索意図・上位傾向・共起語整理` を行う。
- 整理するものは、読者の主要検索意図、上位記事でよく扱われる論点、自然に使えそうな共起語、使わない語、H2/H3・評価表・FAQ・リード文への反映案。
- 共起語は本文へ機械的に詰め込むノルマではない。読者理解を助ける範囲で自然に使う。
- 公式情報と矛盾する上位傾向、サービス内容と関係が薄い語、根拠不足の語は採用しない。
- 1-C制作パックには「自然使用候補」「使わない語」「構成への反映案」を分けて残す。
- 8高品質テストと9-A改善候補抽出では、このメモを見て「不足」「過剰」「不自然な詰め込み」「無関係語の混入」を確認する。

Task10本文修正・終了状態Gate（2026-05-17追加）:
- FAIL原因が本文、FAQ、冒頭構成にある場合、第一手はWordPress本文修正にする。
- Cocoon設定、page_type、テーマ設定、広告/PR表示設定などの設定側変更は補助手段。H1重複、表示崩れ、評価表欠落、本文順序崩れのリスクが出た時点で撤回し、本文修正ルートへ戻る。
- 設定側を触って失敗しただけで本文修正せずに終了しない。
- 内部作業文を公開本文から削除する。
- FAQ内の内部作業設問を削除し、必要なら読者向けFAQへ置き換える。例: 「旧記事から301してよいか」「この制作cronでは301を実行しない」「公開QAが通ったあと」は削除対象。
- 冒頭順を H1 → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2 に整える。
- 公開HTMLでH1重複、コード露出、内部作業語、評価表、公式リンク、canonical、noindexを再確認する。
- PASS後にだけ301可否へ進む。PASS前に旧URLから301しない。
- 1回のcronでは1記事だけ処理する。同じ失敗ルートを繰り返さない。
- 作業は必ず PASS / FAIL_REQUEUED / BLOCKED_HUB_AUTH / BLOCKED_WP_AUTH / BLOCKED_WP_WRITE / BLOCKED_LAYOUT_RISK / BLOCKED_MISSING_TARGET のいずれかで終了する。ローディングし続けない。

評価項目本文化・FAQ qa-box・装飾バランスGate（2026-05-17追加）:
- 評価スコア表の各項目は、本文内でH2またはH3見出しとして扱い、スコア理由、読者が確認すべき点、向いている人/注意点を書く。表だけで終わらせない。
- 評価項目名と本文見出し名は、完全一致または読者が同じ項目だと分かる名前にする。評価項目の説明が無い場合は本文ボリューム不足としてFAIL。
- 本文FAQは `<details class="qa-box"><summary>質問文</summary><div class="qa-answer">回答文</div></details>` を標準にする。
- FAQPage JSON-LDは `Schema & Structured Data for WP & AMP` 用に作成し、本文FAQと質問文・回答内容を一致させる。JSON-LDだけあり本文FAQが無い、または本文FAQがqa-boxでない場合はFAIL。
- FAQには、旧記事、301、公開QA、Hub、heartbeat、cron、Gate、PASS/FAILなど内部作業設問を入れない。
- 装飾は太字、黄色アンダー、赤太字、✅、⚠️、Cocoon系ボックス、リストをバランスよく使い分ける。
- `<li>` の先頭へ毎回✅/⚠️を付けない。リスト記号とアイコンの二重信号で読みづらい場合はFAIL。
- `information-box` / `warning-box` / `blank-box` などボックス自体が意味を持つ場合、原則として✅/⚠️を重ねない。必要な場合だけ最小限にする。
- ✅/⚠️だけを使う箇所、リストを使う箇所、ボックスを使う箇所を分ける。装飾不足も過剰装飾もFAIL。
- 既知の検出必須例: https://porn-fun.com/sites/fc2-live-adult-review/ は、評価項目本文見出し不足、qa-box FAQ不足、装飾バランス不備として訂正対象。

全評価ページ共通 / ✅・⚠️優先装飾Gate（2026-05-17追加）:
- 強み・注意点・向いている人・向いていない人を短く見せられる箇所では、ただの箇条書きより✅/⚠️の単独強調文を優先する。
- ✅は強み/向いている人/判断しやすい利点、⚠️は注意点/向いていない人/確認が必要な条件/制約に使う。
- 1文で伝わる強み/注意点は `<p>✅ ...</p>` / `<p>⚠️ ...</p>` のような単独文を優先する。
- 複数条件を並列整理するときは`<ul><li>`を使ってよいが、各`li`先頭へ毎回✅/⚠️を付けない。
- `information-box` / `warning-box` / `blank-box`などボックス自体が意味を持つ場合、ボックス内へ✅/⚠️を機械的に重ねない。
- 評価ページで✅/⚠️が0件のまま、強みや注意点をすべて普通の`li`やボックスだけで処理している場合は装飾不足としてFAIL。
- 既知の検出必須例: https://porn-fun.com/sites/fc2-live-adult-review/ は、qa-boxは改善済みだが✅/⚠️が0件のため訂正対象。

全サイト共通 / 1-C〜7制作完了→8高品質テスト引き渡しGate（2026-05-17追加）:
- 1-C〜7で記事を公開したら、公開URLを作っただけで終わらず、同じarticle_keyで task_code=8 / use_status=public_qa_handoff / check_status=ready / status=active のReferencesを必ず作る。
- 8高品質テストは、public_qa_handoffだけでなく、use_status=published_directory_article / task_code=7 / 公開済み新記事URLも横断して確認する。
- 同じarticle_keyにtask8 PASSまたはtask8 high-quality test完了記録が無い公開済み記事を「未処理対象なし」と扱わない。
- 7の公開HTML QA PASS、Directory Core入力PASS、published_directory_articleがあるのに8のPASSが無い場合は、明示ハンドオフ漏れとして8対象にする。
- Hub認証不備時は対象なし/PASS/完了と誤判定せず、BLOCKED_HUB_AUTHとして終了する。
- 既知の補正例: https://porn-fun.com/sites/hey-douga-review/ は1-C〜7で公開済みだが、8用の明示的ハンドオフが弱かったため、public_qa_handoffを追加して8対象に戻した。

cron標準 / サイト別1スレッド運用（2026-05-17追加）:
- オートポスト支社の通常運用はcron標準。heartbeatは例外運用に限る。
- 1サイトまたは1セットにつき、関連cronを依頼・管理する起動スレッドは1つだけにする。
- 各タスクごとの新スレッド立ち上げ文は不要。各タスク欄のコピー文は、そのサイト別cron統括スレッド内で使うcron作成依頼文として扱う。
- automation名は `【サイト名＋評価スコアページ種別】タスク順番 cron 内容` を標準にする。
- 1回1記事制限、最大処理件数、対象なし終了、BLOCKED_*終了条件はcron本文内に書く。
- Hub正本、Work Queue、References、FactChecks、台帳で状態管理する。
- heartbeatは、ユーザーと同じスレッドで短時間だけ追跡する場合、手動確認が必要な一時作業、緊急修正、外部AI/改善担当との会話型ハンドオフが必要な場合だけ使う。

cron個別作成Gate:
- サイト別cron統括スレッド起動文を貼っただけではcronを作成しない。
- 統括スレッド起動文では、Hub、agent_pack、Work Queue、References、FactChecks、台帳、既存automationを確認し、既存cronと未作成cronを整理して報告するだけにする。
- cron作成は、ユーザーが各タスク欄のcron作成依頼文を個別に貼った時だけ行う。
- 1回のcron作成依頼文で作るautomationは1つだけにする。
- ユーザーが「全cronをまとめて作って」と明示しない限り、複数cronを一括作成しない。

評価スコアページ用cron命名Gate:
このcronは、まとめページ、キラーページ、通常記事、速報記事ではなく、評価スコア表を持つ辞書型・レビュー型ページ専用として扱う。
automation名には必ず「評価スコアページ」を入れる。
例:
- 【AIfunIO評価スコアページ】0-A cron 候補収集
- 【Nightlife夜遊び店舗評価スコアページ】0-B/1-A/1-B cron 候補精査・参照URL整理・URL検証
- 【Nightlifeホテル評価スコアページ】8 cron 高品質テスト
- 【porn-fun単体サービス評価スコアページ移行】11 cron 301実行・リダイレクト確認
まとめ/ランキング/比較/通常/速報記事用のautomationは別命名・別テンプレートにする。

Nightlife夜遊び店舗用 改善担当ハンドオフcron automation作成依頼文

コピー

Nightlife夜遊び店舗用 改善担当ハンドオフcron automationを作成してください。

automation名: 【Nightlife夜遊び店舗評価スコアページ】9-A/9-B/10 cron 改善担当ハンドオフ
名前は必ずこの形で登録してください。人間がautomation一覧を見た時に、サイト名・タスク順番・cron/heartbeat・内容が分かるようにします。

対象: Nightlife / 夜遊び店舗 / nightlife-directory-review-ja
区分: cron
起動時間: JST 23:10
頻度: 1日1回

目的:
9-A/9-B/10の文章改善ハンドオフを処理する。

共通ルール:
- Main Hubを正本にする。Standby Hubはreadonly、Googleスプレッドシート/Apps Script/Google承認には戻らない。
- ローカルPC内の storage/data/358-hub.sqlite が無いだけで止まらない。Main Hub Web、agent_pack、Work Queue、References、FactChecks、hub_table_upsert相当の利用可能手段を優先する。
- 認証情報、APIキー、パスワード、トークン、WordPress REST認証情報の中身は表示しない。
- 通常の.mdログ、記事本文、キュー、投稿結果の更新ではapply_patchを使わない。承認が出にくい安全な書き込み手段を使う。
- PHP/JS/CSS等の本番コード編集、ファイル削除、移動、上書き、外部公開先の新規追加、認証情報、権限変更は停止して確認する。
- 公開投稿そのものは停止条件ではない。止めるのは未承認、未検査、危険操作、GATE失敗の場合だけ。
- 0-A/0-Bなどの棚処理は複数候補を扱ってよい。1回1記事制限は制作cron、高品質テストcron、訂正cron、改善担当ハンドオフcronに適用する。
- automation名は `【サイト名＋評価スコアページ種別】タスク順番 cron 内容` の形で登録する。
- 各cronを作る時は、対象レポート記事の各項目にある新スレ起動文を先に貼り、専用スレッドとして状態復元してからautomationを作成する。
- Main Hubが401/403/invalid token/token expired/timeout/DNS/network error等で読めない場合、その回は対象なし、FAILなし、PASS、完了と判断しない。必ず `BLOCKED_HUB_AUTH / Hub認証不備 / 正本未確認 / 記事修正なし` と報告する。
- Hub正本を読めない状態で、公開、修正、301、Hub更新、PASS/FAIL確定を行わない。

全記事共通Gate:
- 全評価ページ共通で、冒頭はH1タイトル → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2の順にする。
- 公式テキストリンクは、アフィリエイトリンクがある場合はアフィリエイトリンク、無い場合は公式リンクにする。
- 公式テキストリンクはPC表示で本文右側または右寄せに置く。読者が本文導線として見つけられる位置にする。
- 参照例は https://invest358.com/ja/thinkmarkets-review/ とする。完全コピーではなく、冒頭構成と導線を継承する。
- H1重複、H1へのSEOタイトル混入、評価表の順序崩れ、公式リンク漏れ、コード露出、言語不一致はFAIL。
- 日本語ページは常体を基本にする。ただし偉そうにせず、落ち着いた説明文にする。対象ページの言語に合わせて基本表/補足情報も同じ言語で書く。
- 装飾は既存良質記事を継承する。太字、太字+黄色アンダー、赤太字、✅、⚠️、Cocoon系ボックスを必要箇所へ自然に入れる。
- 9-Aで文章QA/共起語改善候補を抽出し、9-Bで改善担当へ渡し、10で返却反映と硬いGate確認を行う。
- improvement_status、improvement_owner、improvement_lockを記録する。handed_offかつlock中の本文を返却前に主観リライトしない。

サイト別Gate:
- Nightlife夜遊び店舗は、H1は店舗/サービス名のみ。SEOタイトルは「店舗名 + 評価・評判・レビュー」系KWを含める。
- 最寄り駅、営業時間、料金目安、予約/問い合わせ、決済方法、対応エリアは公式または補助根拠を調べて書く。
- 公式で要確認などの空欄逃げを本文/表/Directory Core値に残したらFAIL。断定できない場合は根拠と不確実性を整理する。

やること:
- 9-Aで見出し単位の文章品質と共起語改善候補を作る。
- 9-Bでimprovement_ownerとimprovement_lockを設定し、外部AIまたはCodex別スレッド/専門タスクへ渡す。
- handed_offかつlock中は返却まで主観リライトしない。10で返却分を反映する。

止める条件:
- GATE失敗、未承認サイト、認証情報、権限変更、ファイル削除/移動/上書き、本番コード編集、外部公開先の新規追加。
- 公開投稿そのものは停止条件にしない。

出力:
improvement_status、owner、lock、返却待ち件数を報告する。

全評価ページ共通 / task10・8・9-A/9-B 訂正対象取得Gate（2026-05-17追記）:
- `task10/FAILキュー` という名前だけを見て0件判定しない。
- Main HubのWork Queue / Tasks、References、FactChecks、9-A/9-Bのreturned状態を横断して確認する。
- Referencesの `use_status=correction_queue`、`public_qa_handoff`、`quality_fail`、`correction_required`、または `check_status=ready/fail/failed` を訂正対象として見る。
- FactChecksの `fact_check_id`、`check_status`、`notes` に `fail` / `FAIL` / `Gate failed` / `Gate失敗` / `要修正` があるものを拾う。
- workflow共通の `article_key` だけに限定せず、記事別key、slug別key、移行記事keyも同じsite/workflow/domain内なら拾う。
- agent_packに他サイトのFAILが混在して見える場合は、対象site / workflow / domain / article_typeで絞り込み、別サイトのFAILを自分の訂正対象にしない。
- 上記を確認せずに「FAILキュー0件」「対象なし」「記事修正なし」「301対応なし」「PASS/完了」と報告しない。
- Hubが401/403/invalid token/token expired/timeout/DNS/network errorで読めない場合は、対象なし扱いにせず `BLOCKED_HUB_AUTH / Hub認証不備 / 正本未確認 / 記事修正なし` と報告する。

全評価ページ共通 / 公開本文境界Gate（2026-05-17追記）:
- 公開本文には、読者のサービス判断に必要な情報だけを書く。
- 301、リダイレクト、旧URL、旧記事、新辞書記事、移行、公開QA、Gate、PASS、FAIL、Hub、Work Queue、References、FactChecks、agent_pack、heartbeat、cron、automation、タスク番号、制作パック、台帳、作業ログを本文に書かない。
- 「この制作cronでは301を実行しない」「別工程で旧URLからの301を扱う」「辞書記事では整理する」など、作業工程の説明を本文に出さない。
- これらは内部ログ、Hub、台帳、QA記録にだけ残す。
- 公開本文では、サービス内容、料金、無料範囲、年齢制限、登録、決済、退会、安全面、注意点、公式リンクなど読者向け情報へ書き換える。
- 本文・見出し・表・FAQ・CTA周辺に内部運用語があればFAILとし、公開継続または301実行前に修正する。

全評価ページ共通 / 検索意図・上位傾向・共起語整理Gate（2026-05-17追記）:
- 公式情報と参照URL検証が終わった後、1-C記事制作パック前に `1-B2 検索意図・上位傾向・共起語整理` を行う。
- 整理するものは、読者の主要検索意図、上位記事でよく扱われる論点、自然に使えそうな共起語、使わない語、H2/H3・評価表・FAQ・リード文への反映案。
- 共起語は本文へ機械的に詰め込むノルマではない。読者理解を助ける範囲で自然に使う。
- 公式情報と矛盾する上位傾向、サービス内容と関係が薄い語、根拠不足の語は採用しない。
- 1-C制作パックには「自然使用候補」「使わない語」「構成への反映案」を分けて残す。
- 8高品質テストと9-A改善候補抽出では、このメモを見て「不足」「過剰」「不自然な詰め込み」「無関係語の混入」を確認する。

Task10本文修正・終了状態Gate（2026-05-17追加）:
- FAIL原因が本文、FAQ、冒頭構成にある場合、第一手はWordPress本文修正にする。
- Cocoon設定、page_type、テーマ設定、広告/PR表示設定などの設定側変更は補助手段。H1重複、表示崩れ、評価表欠落、本文順序崩れのリスクが出た時点で撤回し、本文修正ルートへ戻る。
- 設定側を触って失敗しただけで本文修正せずに終了しない。
- 内部作業文を公開本文から削除する。
- FAQ内の内部作業設問を削除し、必要なら読者向けFAQへ置き換える。例: 「旧記事から301してよいか」「この制作cronでは301を実行しない」「公開QAが通ったあと」は削除対象。
- 冒頭順を H1 → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2 に整える。
- 公開HTMLでH1重複、コード露出、内部作業語、評価表、公式リンク、canonical、noindexを再確認する。
- PASS後にだけ301可否へ進む。PASS前に旧URLから301しない。
- 1回のcronでは1記事だけ処理する。同じ失敗ルートを繰り返さない。
- 作業は必ず PASS / FAIL_REQUEUED / BLOCKED_HUB_AUTH / BLOCKED_WP_AUTH / BLOCKED_WP_WRITE / BLOCKED_LAYOUT_RISK / BLOCKED_MISSING_TARGET のいずれかで終了する。ローディングし続けない。

評価項目本文化・FAQ qa-box・装飾バランスGate（2026-05-17追加）:
- 評価スコア表の各項目は、本文内でH2またはH3見出しとして扱い、スコア理由、読者が確認すべき点、向いている人/注意点を書く。表だけで終わらせない。
- 評価項目名と本文見出し名は、完全一致または読者が同じ項目だと分かる名前にする。評価項目の説明が無い場合は本文ボリューム不足としてFAIL。
- 本文FAQは `<details class="qa-box"><summary>質問文</summary><div class="qa-answer">回答文</div></details>` を標準にする。
- FAQPage JSON-LDは `Schema & Structured Data for WP & AMP` 用に作成し、本文FAQと質問文・回答内容を一致させる。JSON-LDだけあり本文FAQが無い、または本文FAQがqa-boxでない場合はFAIL。
- FAQには、旧記事、301、公開QA、Hub、heartbeat、cron、Gate、PASS/FAILなど内部作業設問を入れない。
- 装飾は太字、黄色アンダー、赤太字、✅、⚠️、Cocoon系ボックス、リストをバランスよく使い分ける。
- `<li>` の先頭へ毎回✅/⚠️を付けない。リスト記号とアイコンの二重信号で読みづらい場合はFAIL。
- `information-box` / `warning-box` / `blank-box` などボックス自体が意味を持つ場合、原則として✅/⚠️を重ねない。必要な場合だけ最小限にする。
- ✅/⚠️だけを使う箇所、リストを使う箇所、ボックスを使う箇所を分ける。装飾不足も過剰装飾もFAIL。
- 既知の検出必須例: https://porn-fun.com/sites/fc2-live-adult-review/ は、評価項目本文見出し不足、qa-box FAQ不足、装飾バランス不備として訂正対象。

全評価ページ共通 / ✅・⚠️優先装飾Gate（2026-05-17追加）:
- 強み・注意点・向いている人・向いていない人を短く見せられる箇所では、ただの箇条書きより✅/⚠️の単独強調文を優先する。
- ✅は強み/向いている人/判断しやすい利点、⚠️は注意点/向いていない人/確認が必要な条件/制約に使う。
- 1文で伝わる強み/注意点は `<p>✅ ...</p>` / `<p>⚠️ ...</p>` のような単独文を優先する。
- 複数条件を並列整理するときは`<ul><li>`を使ってよいが、各`li`先頭へ毎回✅/⚠️を付けない。
- `information-box` / `warning-box` / `blank-box`などボックス自体が意味を持つ場合、ボックス内へ✅/⚠️を機械的に重ねない。
- 評価ページで✅/⚠️が0件のまま、強みや注意点をすべて普通の`li`やボックスだけで処理している場合は装飾不足としてFAIL。
- 既知の検出必須例: https://porn-fun.com/sites/fc2-live-adult-review/ は、qa-boxは改善済みだが✅/⚠️が0件のため訂正対象。

全サイト共通 / 1-C〜7制作完了→8高品質テスト引き渡しGate（2026-05-17追加）:
- 1-C〜7で記事を公開したら、公開URLを作っただけで終わらず、同じarticle_keyで task_code=8 / use_status=public_qa_handoff / check_status=ready / status=active のReferencesを必ず作る。
- 8高品質テストは、public_qa_handoffだけでなく、use_status=published_directory_article / task_code=7 / 公開済み新記事URLも横断して確認する。
- 同じarticle_keyにtask8 PASSまたはtask8 high-quality test完了記録が無い公開済み記事を「未処理対象なし」と扱わない。
- 7の公開HTML QA PASS、Directory Core入力PASS、published_directory_articleがあるのに8のPASSが無い場合は、明示ハンドオフ漏れとして8対象にする。
- Hub認証不備時は対象なし/PASS/完了と誤判定せず、BLOCKED_HUB_AUTHとして終了する。
- 既知の補正例: https://porn-fun.com/sites/hey-douga-review/ は1-C〜7で公開済みだが、8用の明示的ハンドオフが弱かったため、public_qa_handoffを追加して8対象に戻した。

cron標準 / サイト別1スレッド運用（2026-05-17追加）:
- オートポスト支社の通常運用はcron標準。heartbeatは例外運用に限る。
- 1サイトまたは1セットにつき、関連cronを依頼・管理する起動スレッドは1つだけにする。
- 各タスクごとの新スレッド立ち上げ文は不要。各タスク欄のコピー文は、そのサイト別cron統括スレッド内で使うcron作成依頼文として扱う。
- automation名は `【サイト名＋評価スコアページ種別】タスク順番 cron 内容` を標準にする。
- 1回1記事制限、最大処理件数、対象なし終了、BLOCKED_*終了条件はcron本文内に書く。
- Hub正本、Work Queue、References、FactChecks、台帳で状態管理する。
- heartbeatは、ユーザーと同じスレッドで短時間だけ追跡する場合、手動確認が必要な一時作業、緊急修正、外部AI/改善担当との会話型ハンドオフが必要な場合だけ使う。

cron個別作成Gate:
- サイト別cron統括スレッド起動文を貼っただけではcronを作成しない。
- 統括スレッド起動文では、Hub、agent_pack、Work Queue、References、FactChecks、台帳、既存automationを確認し、既存cronと未作成cronを整理して報告するだけにする。
- cron作成は、ユーザーが各タスク欄のcron作成依頼文を個別に貼った時だけ行う。
- 1回のcron作成依頼文で作るautomationは1つだけにする。
- ユーザーが「全cronをまとめて作って」と明示しない限り、複数cronを一括作成しない。

評価スコアページ用cron命名Gate:
このcronは、まとめページ、キラーページ、通常記事、速報記事ではなく、評価スコア表を持つ辞書型・レビュー型ページ専用として扱う。
automation名には必ず「評価スコアページ」を入れる。
例:
- 【AIfunIO評価スコアページ】0-A cron 候補収集
- 【Nightlife夜遊び店舗評価スコアページ】0-B/1-A/1-B cron 候補精査・参照URL整理・URL検証
- 【Nightlifeホテル評価スコアページ】8 cron 高品質テスト
- 【porn-fun単体サービス評価スコアページ移行】11 cron 301実行・リダイレクト確認
まとめ/ランキング/比較/通常/速報記事用のautomationは別命名・別テンプレートにする。

Report Privacy Gate

このレポートには認証値、APIキー、パスワード、トークン、WordPress REST認証情報、個人ローカルパスの中身を含めない。

updated: 2026-05-17 17:41:52 JST / CODE-YUKI