第一開発部・CODE-YUKI / CODE-TAKUMI 専用バイブル

2026-05-25 第一開発部スレッド終了記録

記録時刻: 2026-05-25 22:00:43 JST

本スレッドで確定した運用変更

• pending_info は、細かな条件不足だけで制作を止める状態ではなく、本文で注意喚起する材料として扱う方針へ変更した。
• キャンペーン等で一部条件、終了時刻、併用可否、対象範囲などが未確認でも、実在性、公式または準一次情報、遷移先、特典概要、現在有効性の根拠が確認できる場合は、recorded risks 付きで制作へ渡す。
• 制作側は、不足や矛盾を隠さず「確認中」「公式未掲載」「条件変更の可能性あり」「詳細は公式ページで確認」などの読者向け表現に変換する。
• cron には Hub 正本テーブルを書き換える権限を持たせない。正本更新は保守専用権限で行い、通常 cron は読み取りと担当工程の実行に限定する。
• Hub の claim / queue 同期がずれた場合、同一 scope の制作対象が確認でき、358 no-touch lock 等の停止条件がなければ、no-master-table claim bridge として制作を進める。
• 代表が「これはもうさわるな」とした記事・投稿には 358 no-touch lock を使い、以後どのタスクも更新しない。

本スレッドで起きた問題と反省

• OripaGate 制作 cron が、Hub 上に制作対象が見えているにもかかわらず、claim 書き込み不可を理由に投稿を止めた。今後は、認証停止と queue 同期ずれを分け、投稿可能な対象まで止めない。
• OripaGate 通常評価・未開封BOX・TCG店辞書・用語辞書、porn-fun 改善担当などで、同種の停止が他サイトにも波及し得ることを確認した。全サイト共通 Gate と支社ローカル資料へ反映した。
• 支社PC反映用の上書きパックを作成した。支社側では LLC358 フォルダのみを反映対象にし、automation 参照フォルダは比較用として扱う。
• 2026-05-25 の新規公開記事数は、支社分を含めて 12 件として確認した。Hub 書き戻し欠落があるため、次スレでは Hub 側で定時計算する表示へ移す。

開発ツール・Hub 変更履歴

• 358 Hub v0.1.22: hub_table_upsert を保守専用権限に限定し、通常 cron の正本テーブル書き込みを拒否する挙動を確認した。
• Autopost358 runtime: Hub 正本書き込みガードを追加し、通常 cron が誤って正本 upsert を実行しないようにした。
• Autopost358 manuals / agent pack: pending_info 緩和、recorded risks 制作渡し、no-master-table claim bridge、358 no-touch lock を反映した。

次スレで最初にやること

• Main Hub の status、agent_pack、Rules、Manuals、Work Queue、Task Test を再確認する。
• 支社PCへ反映したローカル資料で、hub_table_upsert 403 を BLOCKED_HUB_AUTH と誤判定して止めないことを確認する。
• Hub v0.1.23 として、トップ上部に「本日の新規公開記事数」「残存するアップデートリクエスト」「最終集計時刻」を表示する設計から入る。
• Hub の SQLite から MySQL / MariaDB への移行は、大工事として dual DB layer、移行テスト、本番切替の順で進める。現行 SQLite はバックアップを残して破壊しない。
• Search Compass は引き続き後日開発扱いとし、今回の大工事の主作業に混ぜない。

終了チェック

• 秘密値、認証値、不要な個人情報、個人ローカルパスはこの終了記録へ記載していない。
• 古い page-434 記録は削除せず、今回分を追記として残す。
• このスレッド用 page-434 heartbeat は、終了記録後に削除する。

2026-05-24 第一開発部 日次レポート

記録時刻: 2026-05-24 23:51:38 JST

代表からの指摘・怒られ

• OripaGate通常評価3記事で、Cocoonの評価スコアが0.0または空星のまま表示され、通常評価記事として成立していないと指摘を受けた。
• 通常評価記事の冒頭順は、評価スコア表、完結したリード文、右寄せの公式またはアフィリエイトテキストリンク、目次、最初のH2に固定する必要があると再確認した。
• 通常評価本文では、評価理由などの記事ごとの自然なH2配下に、評価項目ごとのH3を必ず置く。親H2名は固定しない。
• H1はショップ名・サイト名・店名のみ。SEOタイトル側で対象名と評判・評価・レビュー系キーワードを持たせる。
• cron実装前に代表または人間が投稿した通常評価記事も、高品質チェック対象から漏らしてはいけない。
• 通常評価記事は実質本文4000文字以上を基本とし、足りない場合は加筆で調整する。加筆後にキーワード、装飾、H2/H3、Q&A、公式導線のバランスを再確認する。
• 全OripaGate cronで、最新cron指示を読んだ証跡をGate条件にする。古い指示のまま次工程へ渡さない。
• Hubへ到達しやすくし、同時接続・マルチタスク運用ができる実行前レイヤーを準備するよう指示を受けた。
• 実装準備中に「承認でとめるな」と強く指摘された。通常更新・ログ追記・docs更新・runner準備で不要な停止を挟まない。

過ち・不足

• Cocoon数値星、H1とSEOタイトル分離、親H2配下の評価項目H3を、通常評価Gateとして十分に強制できていなかった。
• 制作済みまたは人間投稿済みの記事を、高品質チェックの対象範囲として明文化できていなかった。
• cronテンプレートや実行文が古い状態のまま進む危険を、通常評価以外のOripaGate cronまで横断して止める条件にできていなかった。
• Hub到達性について、既存の60秒timeoutでは回線不安定時に粘りが足りない可能性があった。

再発防止策

• OripaGate通常評価の高品質チェックでは、Cocoon数値星、冒頭順、公式バッジ、H1とSEOタイトル分離、親H2配下7H3、4000文字以上を必須確認にする。
• 親H2名は記事ごとに自然化し、H3には使いやすさ、オリパの種類、演出・楽しさ、特典・キャンペーン、発送・確認しやすさ、情報の分かりやすさ、総合評価を必ず展開する。
• 公開済み通常評価記事18件を既存記事棚卸しとして扱い、cron作成記事だけを検査対象にしない。
• 全OripaGate cronで、最新cron指示確認の必須出力を持たせる。古いpackや古い発火文を検出した場合は、最新指示との差分を反映してから次工程へ渡す。
• Hub未読を対象なし、PASS、完了、readyなしにしない。Hub到達性runnerでpreflightを先に通し、claim後はHubを読み直してlock ownerを確認する。
• 通常の追記、docs更新、共有ログ更新、runner準備は止めずに実行する。停止は削除、権限変更、認証情報、公開Gate失敗継続、法務・安全上の危険に限定する。

開発ツール・バージョン履歴

• 358Hub: hub_version=0.1.22。Main Hubを正本、Standby Hubをreadonlyとして維持。
• OripaGate通常評価Gate: 2026-05-24版。Cocoon数値星、H1/SEO分離、親H2配下7H3、高品質FAIL条件、4000文字以上、既存記事対象化を追加。
• OripaGate全cron最新指示Gate: 2026-05-24版。通常評価だけでなく、キャンペーン、O/オリパ辞書、用語辞書、TCG店辞書、未開封BOX、トレカカード等へ横断適用。
• cron置き場: 2026-05-24版。OripaGate専用14記事へ最新cron指示確認Gateを反映し、通常評価2記事へ4000文字・既存記事対象Gateを反映。
• OripaGate通常評価automation: 2026-05-24版。既存6本の発火文へ追加Gateを反映し、ACTIVE維持と構文確認を行った。
• Hub Reachability + Task Claim Runner: 2026-05-24-hub-reachability-claim-runner-prep-v1。全体12、読み取り24、Hub書き込み4、claim4、サイト本流3、workflow production 1で準備。Hub timeoutは60秒から120秒へ更新。
• Autopost358 portable runtime: 2026-05-24更新。既存bootstrapのHub timeout既定値を120秒へ更新。

確認結果

• Main Hub status、runtime readiness、work queue のpreflightは成功。work queueは34件を確認した。
• Hub Reachability runnerのread probeは2件中2件成功した。
• 公開本文には秘密値、認証値、不要な個人情報、個人ローカルパスを記載していない。

2026-05-24 OripaGate cronテンプレート・Q&A運用不備の反省

記録時刻: 2026-05-24 07:35:30 JST

反省文

OripaGateのcronテンプレート修正で、代表から繰り返し指示されていた「実際にコピペする依頼文の中に書かなければcronへ伝わらない」という基本を守れなかった。外側の説明欄に重要Gateを書き、さらに修正時に見出しや既存構成まで消しかけた。これは、日本語の指示を読んだつもりで、実際の運用導線を見ていなかった重大な失敗である。

また、Q&Aについても「当社標準のデザインを固定する」という指示を、「質問文まで固定してよい」と誤って扱いかけた。固定すべきものは details.qa-box のHTML構造だけであり、FAQの質問文・summaryは記事ごとの検索意図、対象名、相場、状態、期間、注意点、関連語に合わせて変える必要がある。この区別を即座にできなかったことを反省する。

今回怒られた内容

• cron立ち上げスレッドの記事に、コピペ依頼文以外の重要説明を書いた。cronが読まない場所に書いても意味がない。
• 「依頼する文テンプレート以外のものを書くな」という指示を守らず、外側Gateを足した。
• 修正時に余計なものまで消し、見出し・見やすさ・既存構成を壊しかけた。
• Q&Aデザイン固定とFAQ質問文固定を混同した。
• 代表が何度も言っている運用ルールを、作業の途中でまた踏み外した。

再発防止策

• cronテンプレート記事では、実行上重要なルールは必ずコピペ対象の依頼文内に入れる。外側に書いてよいのは、人間が選ぶための見出し、ラベル、最低限の区切りだけにする。
• テンプレート編集前に、本文ブロックを「コピペ対象」「人間用見出し」「説明」「自分が後から足したGate」に分類し、削除対象を限定する。
• 見出し、表、既存の補助説明は勝手に消さない。不要なのは、自分が誤って足した外側Gateだけ。
• Q&Aは、HTML構造だけを全社標準に固定する。質問文、summary、FAQセットは固定せず、記事ごとの検索意図・共起語・関連語・対象情報から作る。
• 「全部同じQ&Aになる」恐れがある例文は、禁止例としても安易にテンプレートへ残さない。必要な場合は抽象ルールとして書く。
• 公開テンプレート修正後は、対象記事数、固定見出し、コピペ依頼文内の反映数、外側Gate残存なし、固定FAQ文言なしを機械確認してから完了報告する。
• 誤って消しすぎた場合は、WordPressリビジョンから戻し、戻した内容と残した修正を分けて報告する。

実施済みの是正

• OripaGate関連cronテンプレート14本について、消しすぎた構成をリビジョンから復元した。
• 自分が追加した外側Gateを削除し、共通ルールは各コピペ用依頼文の中へ移した。
• Q&Aは「デザイン固定、質問文は記事ごとに可変」としてHub、公開テンプレート、Autopost358側資料、デスクトップ持ち出し資料へ反映した。
• 固定FAQ質問例は削除し、同一FAQセットの固定流用禁止として抽象化した。
• page-434の固定見出しは移動せず、この反省文を加筆した。

開発ツール・資料更新履歴

• OripaGate cronテンプレート修正: 2026-05-24版。外側Gate削除、コピペ依頼文内ルール化、見出し復元、FAQ可変ルール反映。
• Main Hub Q&Aルール: 2026-05-24版。details.qa-box 構造固定、FAQ質問文可変、固定FAQセット流用禁止を反映。
• Autopost358 OripaGate資料: 2026-05-24版。通常評価、キャンペーン速報、O/オリパ辞書、用語辞書、TCG店辞書、未開封BOX、トレカカードの各資料へ反映。

第一開発部 現行スレッド総合レポート（2026-05-18〜2026-05-22）

このセクションは、第一開発部の現行スレッド内で実際に発生した指摘、怒られたこと、判断ミス、修正方針、開発ツールの更新履歴をまとめた記録である。次スレ立ち上げ時は、この記録を読んでから作業に入る。

今回代表から強く指摘されたこと

• 質問と実行指示を取り違えた。確認だけの発言に対して、勝手にHubやテンプレートを更新する動きがあった。
• 過去に指摘された4つの評価ページ参考URLを忘れ、別の参考資料と混同した。
• cronがHubを見るだけで完結する設計にすべきところ、Hub側の指令・Gate・TaskTemplateが不完全な状態で進めた。
• 立ち上げスレッド文と個別cron作成依頼文の役割を混同した。スレッド立ち上げ時にcronを作ってはいけない運用を忘れた。
• cron一式作成依頼文とH3個別cron作成依頼文を混同した。一式作成依頼文だけで必要なcronを作れるよう、各cron名、TASK_STAGE、対象工程、識別子、起動回数、起動時間、cwd、model/reasoning、既存cron非変更条件を入れる必要がある。
• cron置き場記事をスクリプトで一括編集し、文字化けや内容不足、余計な説明を混入させた。代表から「一個一個丁寧にやれ」と強く指摘された。
• 支社PCでは技術者がいない前提なのに、本社側で直接cronスクリプトを直せば済むような運用に寄っていた。支社cronは次回起動時にHub正本から最新指令を読む設計が必要だった。
• 支社移転後に必要なファイルと、本社テスト用ファイルを切り分けきれていなかった。アップデートに必要な最小差分だけを渡す配慮が不足していた。
• 公開本文に内部調査語や制作都合が露出した。「検索意図」「上位傾向」「共起語」「関連語」「Search Compass」「Gateでは」などは読者向け本文に出してはいけない。
• Directory Coreで、カテゴリに入れるべきものとタグに入れるべきものを混同した。NSFW AIなど大分類は辞書カテゴリ、機能・評価軸・料金系などは辞書タグにする必要がある。
• 記事品質Gateが甘く、公式バッジ、黄色アンダーマーカー、赤太字、✅/⚠️、qa-box、H2/H3構成、常体Strict、文章量、見本ページ照合、内部語露出を十分に検知できていなかった。
• 高品質cronが同じ記事を何度も検査したり、並行実行でPASS/FAILが分かれる挙動があった。quality claim、soft lock、最新判定、同一記事のactive状態整理が必要になった。
• 301 cronがactive correction_queueやstale quality failと衝突し、301実行対象にならない状態があった。301は品質PASS後、active correctionがない状態だけで実行する。
• 「長文をHubへ突っ込むこと」と「テンプレートページに必要情報を書くこと」を混同した。Hubは詳細Gateの正本、cron置き場は支社がコピペする依頼文として分離する必要がある。
• 承認不要の通常作業で確認を挟みそうになった。通常ログ追記、報告追記、テンプレート軽微更新では止めない。

cron・Hub・支社運用で発生した問題

• Main 358 Hubを正本とし、cron.goudou-358.jpはテンプレート置き場とする方針を確認した。
• Hub認証が壊れた場合は、対象なし、PASS、完了、readyなしとは扱わず、BLOCKED_HUB_AUTHまたはBLOCKED_HUB_NETWORKで止める方針を徹底した。
• WordPress認証が切れた場合はBLOCKED_WP_AUTHとし、本文・Directory Core・FAQ JSON-LD・301には進まない。
• 支社PC用に、Autopost358配下の共通bootstrap、Hub token、WP認証env、branch envを読む構成を整えた。
• Hub tokenは再発行で既存トークンを壊さないよう、Agent API tokensをPC/支社ごとに追加する方式へ切り替えた。
• 支社側では、既存cronを本社PCからコピーしても動かないため、支社PCでcronを新規作成する必要があると確認した。
• cron表示用cwdは、支社・本社で共通化しやすいよう、LLC358直下の _codex_cron_threads を使う方針にした。
• 支社PCでCodex automation runtimeが白紙実行になる問題が発生した。最小テストautomationでも白紙になり、Codexアプリ側のautomation runtime / thread binding / project cwd問題として切り分けた。
• 支社PCではRun nowを押しても白紙になる問題があり、Codex側のプロジェクト認識、automation cwd、.codex状態、アプリキャッシュ、手動テストを確認した。
• その後、支社PCのcronが動く状態まで戻ったが、Hub接続でBLOCKED_HUB_NETWORKが発生し、Node fallbackやPowerShell/Python実行経路の扱いが問題になった。
• cron起動時に、起動時指令マニフェストを出し、Hub必須参照、対象識別子、禁止行為、block code、runtime lesson、version_up_requestを確認する仕様を追加する方針にした。
• cronが長時間トライ＆エラーで成功した場合は、成功ルートをHubにruntime_lessonとして残す方針にした。
• cronが止まった、迷った、回避策で通した、仕様不足を見つけた場合は、runtime_issue_report / version_up_requestとしてYUKI改善リストへ積む方針にした。
• 同時起動対策として、0分固定を避け、07 / 13 / 19 / 26 / 34 / 41 / 48 / 55などの分散しやすい分を候補にする「作成時刻分散Gate」を導入した。ただし特定分を避ける判断はPC固有であり、全社共通Gateに固定しない。
• 制作cronは一回起動したら次の起動まで最低3時間あけるルールを追加する必要が出た。

評価スコア記事品質で発生した問題

• 見本評価ページ4URLを品質判断の参照として扱うことを再確認した。対象は Errante、ThinkMarkets、Pollo AI、CrowdWorks AI。
• 見本ページは完全コピーではなく、構成、導線、装飾バランス、情報密度を見るための参考とする。
• 評価スコア記事の冒頭構成は、H1、評価スコア表、リード文、公式テキストリンク、最初のH2を守る。
• H1とSEOタイトルを混同しない。H1にSEOタイトルを混ぜない。
• 公式テキストリンクは本文右側または右寄せにし、<span class="badge badge-red">公式</span>を含む形にする。
• 黄色アンダーマーカーは <b><span class="marker-under">...</span></b> のセットを基本にする。
• 赤太字が0件、✅/⚠️が0件、装飾バランスが薄い場合はFAIL候補にする。
• ✅/⚠️とliを重複させすぎない。ボックスとマークは分けて使う。
• FAQは <details class="qa-box"> 形式を基本にし、本文FAQとFAQPage JSON-LDを一致させる。
• FAQ JSON-LDのscriptを本文に直接入れない。WordPress側のカスタムJavaScriptまたは指定欄へ分離する。
• 常体Strictを導入した。ですます調が混ざればFAILまたは訂正対象にする。
• 評価項目の内容は見出しコンテンツ化し、点数だけで終わらせない。
• 主要H2にはIDを付け、必要に応じてsection IDを付ける。
• H2ばかりにならないよう、良い点、注意点、向いている人などはH3化する方針にした。
• 記事全体の文字数が少なすぎる場合はFAIL候補にする。4000文字未満は基本的に不足扱い。ただし文字数上限は設けず、自然な加筆で補う。
• リード文は500文字固定では長すぎるため、220〜360字程度を基本にし、必要なら2段落、最大420字程度とする方針にした。
• リード文冒頭の「○○の評判は」は不自然なため避ける。サービス説明、利用前の判断軸、この記事で確認する内容へ自然につなげる。
• 「○○ 評判」などのKWは本文では「○○の評判」「○○を評価する時」など自然な日本語に変換する。
• 検索意図、共起語、関連語、上位傾向は内部調査用であり、公開本文にそのまま出したらFAILとする。
• 加筆修正後は、メインKW、共起語、関連語、装飾黄金比、H2/H3、常体Strict、FAQ、公式導線を再計測する。
• 制作cronは50〜80点以上で高品質へ渡す。ただし明白な最低品質NGを高品質へ丸投げしない。
• 高品質cronは残りの不足20〜50点を具体的に抽出し、訂正cronへ渡す。本文を直接直す役ではない。
• 訂正cronは不足分を潰して100点化し、公開HTMLまたはプレビューHTMLで再確認してready_for_retestへ返す。

Search Compass・キーワード密度・共起語関連

• Search CompassはPython本命の構想だが、現時点では共有サーバー上のPHP API fallbackとして、キーワード密度、共起語、検索意図、網羅性チェックを使う方向にした。
• キーワード密度は、単純に「サービス名 + 評判」の全体を3〜5%にするのではなく、サービス名、修飾語、自然な複合KWを3層で扱う方針にした。
• 「評判」だけを3〜5%にしようとすると不自然になるため、本文では「評価」「レビュー」「使う前に確認」「登録前」など自然な関連表現へ分散する。
• 密度不足時は加筆するが、追加項目にはIDを付け、まとめ前など自然な位置に置く。
• Search Compassの結果は公開本文に出さず、読者向けには「料金、解約、安全性、公式情報で確認できた内容」へ変換する。

porn-fun / Directory Core / 新ジャンルで発生した問題

• porn-fun辞書記事のURLから /sites/ を外し、/ja/ 配下の日本語ページ構造へ移行する確認を行った。
• porn-fun日本語トップ正本は https://porn-fun.com/ja/top/ から https://porn-fun.com/ja/ へ整理した。
• Directory Coreのカード表示でサムネイルサイズがカード枠とボタン枠を崩していたため、CSSでカード画像サイズを制御する必要が出た。
• 成人向けサービス辞書の大カテゴリとして、動画配信、ライブチャット、Hentai Games、NSFW AI、アダルトグッズ通販、セックスドール、実店舗型アダルトショップを整理した。
• Hentai Games、NSFW AI、Sex Dollは新規ジャンル記事として、移行ではなく0-A〜10の通常評価スコアワークフローにする。301は不要。
• NSFW AI候補は PornDudeAI を参照元にするが、PornDudeAI自体は候補に入れない。
• ThePornDudeはHentai GamesやSex Dollの参照元にするが、ThePornDude自体は候補に入れない。
• NSFW AIでは、AI Companion Chat、AI Image Generator、AI Video Generatorなどの機能系は辞書カテゴリではなく辞書タグに入れる。
• プライバシー・安全面、使いやすさ、商品・コンテンツ、料金・費用、決済・配送、海外対応、退会・キャンセルなども辞書タグ扱いにする。

cron置き場・テンプレートで発生した問題

• cron置き場の記事は、支社でコピペするものだけを書く。説明やGate全文を無駄に長く入れすぎない。
• 詳細Gate、TaskTemplate、runtime lesson、version_up_requestはHub正本を見る。
• H2「スレッド立ち上げ依頼文」、H2「cron一式作成依頼文」、H2「個別cron作成依頼文」を分ける。
• 個別cron作成依頼文内では、cron別にH3を付ける。
• cron一式作成依頼文を使う場合、H3個別cron作成依頼文は使わない。併用しない。
• cron一式作成依頼文だけで全cronを作れるよう、作成するcron一覧、各cron名、TASK_STAGE、対象工程、WORKFLOW_ID、ARTICLE_KIND、CRON_FAMILY、CONTENT_SET、SITE_KEY、DIRECTORY_COLLECTION、DIRECTORY_CATEGORY、1日の起動回数、起動時間ルール、既存cron非変更条件、cwds、model/reasoning、Hub参照義務を入れる必要がある。
• 既存automation / cronは参照のみ。編集、停止、削除、上書き、時刻変更は禁止。変更したらFAILED_EXISTING_AUTOMATION_MUTATEDと報告する。
• 各cronの起動回数と起動時間はマスト。特に制作cronは最低3時間間隔を空ける。
• cron名は「サイト名【記事タイプ・ジャンル短縮】工程cron」とする。例: porn-fun【評価・NSFW AI】収集cron。

再発防止策

• 作業前に、質問なのか実行指示なのかを必ず切り分ける。
• 「確認だけ」と言われた時は勝手に編集しない。
• テンプレート、Hub、cron置き場、公開記事、ローカルログの役割を混同しない。
• cron置き場は支社がコピペする依頼文。HubはGateとTaskTemplateの正本。ローカルログは開発記録。
• 既存記事を触るなと言われた時は、新規記事またはローカルメモだけに留める。
• スクリプト一括処理が危険な場面では使わず、1記事ずつ差分を確認して更新する。
• 文字化けが出た場合は即停止し、対象記事を広げない。
• cron一式作成依頼文を編集する時は、個別cron作成依頼文と混ぜない。
• 支社運用では、本社の直接修正に依存しない。cronが次回起動時にHub正本から最新仕様を読む設計を優先する。
• page-434には、日次で指摘・怒られ・対策・バージョン履歴を残し、次スレ起動時に必ず読む。

開発ツールバージョンアップ履歴

358hub

評価スコアcron Hub正本化強化（2026-05-18〜2026-05-22）

評価スコアcronが起動時に Main 358 Hub の agent_pack、agent_work_queue、agent_runtime_readiness、TaskTemplate、Rules、Manuals、Checks、runtime lessons、version-up requestsを読む方針を強化した。Hubが読めない場合はBLOCKED扱いに固定した。

runtime_lesson / version_up_request / 起動時マニフェスト追加方針（2026-05-20〜2026-05-22）

cronが長時間のトライ＆エラーで成功した時の成功ルート、止まった時の改善要求、起動時指令マニフェストをHubに残す方針を追加した。

page-434日次・終業レポート運用（2026-05-22）

第一開発部スレッド立ち上げ時・閉じる時の反省、指摘、怒られ、対策、バージョン履歴をpage-434へ記録する運用を追加した。

Autopost358 支社bootstrap

支社PC移転用bootstrap整備（2026-05-21〜2026-05-22）

支社PCでAutopost358のみを持っていく前提で、Hub token、Hub env、branch env、WordPressサイト別env、共通runtime、_codex_cron_threads cwdを確認する初回セットアップとチェックスクリプトを整備した。

Agent API token複数発行方式（2026-05-21）

既存Hub tokenを再発行で壊さないため、PC/支社ごとにAgent API tokenを追加する方式へ切り替えた。

cron置き場

cron一式作成依頼文の要件整理（2026-05-21〜2026-05-22）

cron一式作成依頼文は、個別cron作成依頼文を併用せず、それ単体で全cronを作れる必要があると整理した。起動回数、起動時間、対象識別子、既存cron非変更条件、cwds、model/reasoning、Hub参照義務を必須項目にした。

Search Compass

キーワード密度・共起語・検索意図チェックAPI方針（2026-05-19〜2026-05-20）

検索意図、共起語、関連語、KW出現率、網羅性チェックを、公開本文に露出させず、内部判断材料として使う方針を追加した。

Directory Core / porn-fun辞書

カテゴリ・タグ分離方針（2026-05-21）

NSFW AIなどジャンルは辞書カテゴリ、AI Companion Chatや料金・安全面など機能・評価軸は辞書タグに分ける方針を追加した。

第一開発部 日次終業報告 2026-05-23 / OripaGate Oオリパ辞書cron

本日の主作業は、OripaGateの通常評価記事・キャンペーン速報・オンラインオリパ辞書のcron設計を分離し、O/オリパ辞書cronの立ち上げテンプレートと単独使用版をcron置き場へ公開することでした。通常評価記事と辞書記事の役割を混同しないこと、他サイトcron・他サイトHub・既存automation設定は変更なしで進めることを再確認しました。

当日の指摘事項

• 通常評価記事と辞書記事を混同しない。通常評価記事は手書き評価表、辞書記事はDirectory Coreの基本情報項目を使う。
• オンラインオリパ辞書記事の本文は「何のページか」「情報は確認日ベースで更新されること」「通常評価記事への導線」の3要素だけにする。
• 辞書記事の右寄せ内部リンクは、DOPA!オリパを固定文言にせず、対象サイト名ごとに変える。
• オンラインオリパ辞書記事のH1はサービス名、SEOタイトルは「サービス名の基本情報」にする。H1を「サービス名の基本情報」にして辞書一覧を不自然にしない。
• cron名は長すぎるため、OripaGate【O/オリパ辞書】を正式ラベルにする。
• cron発火ルールでは固定時刻は指定しない。1日の起動回数と、朝・昼・夕・夜などの分散方針、既存ACTIVE cronとの衝突回避だけを書く。

怒られた内容・強い注意

• 通常の追記・更新・明確に依頼された投稿で、不要な承認待ちで止めない。
• 途中で確認を求めて代表の作業を止めない。必要な停止条件と不要な確認を混同しない。
• 「推奨起動 07:10 / 11:40」のような固定時刻に見える書き方を残さない。
• 触ってよい範囲はOripaGate関連のみ。他サイトのcron、Hub、既存automation設定を編集・停止・時刻変更しない。
• 辞書記事の導線文で、例示のサービス名を全記事共通の固定文として扱わない。

再発防止策

• 通常ログ、テンプレート更新、明示された公開投稿は、作業してから短く報告する。
• cronテンプレートでは固定時刻を書かず、起動回数、時間帯バランス、既存cron衝突回避、既存automation非変更を必須項目にする。
• 公開後は、HTTP 200、カテゴリページ掲載、全cron名、Hub参照ID、秘密値露出なしを確認する。
• 記事仕様が決まったら、HubのRules / Manuals / Checksに反映し、agent_packで読める前提の参照IDをテンプレートにも残す。
• H1とSEOタイトルの役割を分け、一覧で見えるH1を不自然に長くしない。
• 作業スコープ確認として、他サイトcron・他サイトHub・既存automation設定は変更なしを終業報告へ明記する。

開発ツール・バージョン履歴

• Main 358 Hub: hub_version=0.1.22 / Hub内SQLite正本方針を維持。
• Directory Core: v0.1.40.15 / オンラインオリパ基本情報項目テンプレートを利用。
• OripaGate Portal: v0.1.18-WP-UPLOAD-READY-20260523-063908 まで作成済み。辞書セット導線、サイドバー、ショートコード表示補正を反映した系統。
• cron置き場: OripaGate【O/オリパ辞書】cron専用スレッド立ち上げ定型文・個別cron作成依頼テンプレート を更新済み。
• cron置き場: OripaGate【O/オリパ辞書】cron一式作成依頼文（単独使用版） を更新済み。
• Hub登録: oripagate-o-oripa-dictionary-cron-name-rule-v1 / oripagate-online-oripa-dictionary-body-three-elements-rule-v1 / oripagate-online-oripa-dictionary-review-reference-link-rule-v1 / oripagate-online-oripa-dictionary-h1-seo-title-rule-v1。

検証結果

• 公開済みcron置き場記事 938 / 940 はHTTP 200、カテゴリ掲載、6 cron名、3要素本文ルール、H1/SEO分離ルール、Hub参照IDを確認済み。
• 公開本文、Hub本文、配布物、ログへ秘密値や認証値は書いていない。
• 他サイトcron・他サイトHub・既存automation設定は変更なし。

第一開発部 スレッド終了レポート（2026-05-23 / OripaGate・Standby・cron運用）

このセクションは、2026-05-18開始の第一開発部継続スレッドを次スレへ移す前の終了レポートです。既存情報は削除せず、今回のスレッド内で代表から指摘されたこと、怒られたこと、再発防止策、開発ツールのバージョン履歴を追記します。秘密値、認証情報、個人ローカルパスは記載しません。

代表から指摘されたこと・怒られたこと

• Standby Hub対応では、CODE側でできる作業まで代表へ手順実行を求めてしまった。アップロード以外はCODEが準備し、アップロード対象ZIPだけが分かるフォルダを開くべきだった。
• アップロード用フォルダに不要なファイルが混ざり、代表から「アップロードするファイルだけ分かるようにしろ」と強く指摘された。
• page-434の固定見出し位置を崩し、固定と書かれた見出しより上へ日次報告を差し込んだ。固定セクションをアンカーにし、その上を触らない運用が必要だった。
• OripaGateのトップ設計で、記事内だけを整形してサイト全体の横幅・サイドバー・カテゴリ/タグページ・各ページとの差を見落とした。
• OripaGateの背景デザインで、画像と背景色の切り替わりがくっきり見える状態を残した。自然なフェード、端処理、背景画像の終端確認が不足していた。
• スマホメニューで文字が白く消え、PC/スマホ両方でメニューテキストを常時読める状態にできていなかった。
• 「記事内の表が今はいらない」という指示を、画像枠の話と誤解した。代表から「確認を取ってから作業しろ」と強く叱責された。
• 辞書記事の表をCSSで非表示にする案を出し、将来使う時に困る設計になりかけた。非表示ではなく、今は表が出る記載・ショートコード・本文構成を入れないことが正しい。
• TOP右サイドのランキングに、実在ショップではなく「オリパアプリ」「通販型オリパ」「実店舗連動オリパ」「トレカ通販・買取店」などジャンル/業態項目を混ぜてしまった。
• ランキングを実サイトだけに絞った結果、辞書側に実サイトがDOPA!オリパ1件しかなく、右サイドが1件表示になった。通常レビュー記事側から実サイトを補完する判断が必要だった。
• AiFan.io辞書投稿時にカテゴリを乱立させすぎた。カテゴリ・タグ・辞書タイプ・カスタムフィールドの役割分担を明確にしてから高品質チェックへ渡す必要がある。
• 検査cronが必要以上に止まり、制作レディが貯まらない問題を指摘された。記載なし、調査中、調査したが情報見つからず、公式リンクなし、閉鎖などを記事本文で成立させる運用が必要だった。
• 法務・年齢制限・海外法域に関する検査で、掲載禁止が明確でないものまで止めすぎる傾向があった。記事内に注意喚起を書かせ、次工程へ渡す運用が必要だった。

再発防止策

• 代表が「アップロードする」と言った作業以外は、CODEがZIP作成、GATE、対象フォルダ表示、表示確認まで行う。フォルダにはアップロード対象ZIPだけを見せる。
• page-434更新時は、固定見出しセクションを必ずアンカーにし、その上には絶対に挿入しない。アンカーが見つからない場合は更新を止め、BLOCKED_REPORT_STRUCTUREとして報告する。
• UI修正では、トップだけでなく固定ページ、通常記事、辞書記事、カテゴリページ、タグページ、PC、スマホ、サイドバー位置を同じ確認範囲に入れる。
• 「消す」「非表示」「表」「画像枠」「サイド」「辞書セット」など対象が曖昧な指示は、作業前に対象を1文で復唱し、認識が合ってから触る。
• 一時的に使わない表はCSSで隠さない。本文・ショートコード・メタ出力側で、表が出る記載を入れない。
• 右サイドの「おすすめオリパサイト」は実在サイト/サービスだけを出す。ジャンル、業態、辞書項目は「ジャンルで探す」「辞書セット」へ分離する。
• OripaGateのランキング導線は固定ページ https://oripagate.jp/recommended-ranking/ を正とし、TOPメニューと右サイドの「ランキングをもっと見る」から接続する。
• 検査cronは、情報不足をすぐ停止にせず、独自採点で通過可能にする。2回以上同じ理由で止まる場合は「記載なし」「調査したが情報見つからず」「公式リンクなし」「閉鎖」等の表現で本文化し、注意喚起を付けて次工程へ渡す。
• 法務・年齢制限・海外法域は、掲載自体が明確に禁止される場合を除き、本文内注意喚起と自己責任導線で扱う。ただし違法行為の助長、危険な誤情報、明確な公開禁止は停止対象にする。
• AiFan.io辞書では、親カテゴリは大分類、子カテゴリは主要用途、タグは細かい機能・条件・料金・対応形式に寄せる。多機能サービスは複数子カテゴリを許容できるが、カテゴリ乱立が気になった時点で再設計する。
• 作業途中で代表が「ちょっと待って」と言った場合は、直前の作業を止め、次の明示指示まで実装を進めない。

開発ツールバージョンアップ履歴

358hub

Standby snapshot同期運用（2026-05-22）

Main Hubのsnapshot作成、Standby適用、主要件数照合、ログ保存までを一括で行う半自動snapshot同期を整備しました。実行結果はOKで、Standbyはreadonly運用、通常書き込みはMainのみです。snapshot件数差はMain側の過去snapshot保存数とStandby側の適用履歴数の差であり、主要データ不一致とは扱わない方針です。

Standby同期段階方針（2026-05-22）

段階は、半自動snapshot同期、定期自動snapshot同期、差分同期、手動承認付きフェイルオーバー、完全自動フェイルオーバーの順で進めます。完全自動フェイルオーバーは、DNS/入口切替、write fence、primary_epoch、復旧時の衝突処理が完成してから扱います。

cron templates

検査cron v6.7追記方針（2026-05-23）

検査cronが必要以上に止める問題に対応するため、情報不足・公式リンクなし・調査不能・閉鎖・法務/年齢制限リスクをすぐ停止にせず、本文内注意喚起と独自採点で次工程へ渡す方針を追記しました。cron作成依頼文そのものは変更不要と整理しました。

Directory Core

v0.1.40.15（2026-05-22）

OripaGate用に、辞書セット、辞書タイプ、辞書カテゴリ、辞書タグを使う初期骨組みを確認しました。オンラインオリパ辞書、オリパ用語辞書、トレカカード辞書、未開封BOX・パック辞書、トレカ通販・買取店辞書、キャンペーン・招待コード辞書を分ける設計にしました。

OripaGate Portal

v0.1.0 – v0.1.6（2026-05-22）

OripaGateトップ専用ポータルプラグインの初期実装、ZIP package gate、トップ/通常ページ/カテゴリ/タグ/サイドバー対応、ダークブルー系背景、ヘッダー/ナビ/サイドパネル調整を行いました。初期ZIPではWordPressが読めない構造の失敗があり、以降のpackage gateで修正しました。

v0.1.7 – v0.1.12（2026-05-23）

背景画像の切り替わり、段差、くすみ、ページ全体の暗さ、スマホ表示、旧TOP残り、ページ幅、サイドバー位置を継続修正しました。背景はカード開封ステージ風の青系に寄せ、境目が出ないように調整しました。

v0.1.13 – v0.1.15（2026-05-23）

TOP右サイドの辞書セット配置、スマホメニューの文字色、古いTOP表示対策、記事側の不要な表記・表出力に関する修正を行いました。表をCSSで隠すのではなく、表が出る記載を本文から外す方針を明確にしました。

v0.1.16（2026-05-23）

TOPメニュー「ランキング」と右サイド「ランキングをもっと見る」を https://oripagate.jp/recommended-ranking/ へ接続しました。また、右サイドランキングがジャンル/業態を拾っていたため、辞書側の実サイトタイプへ絞る修正を行いました。

v0.1.17（2026-05-23）

v0.1.16では実サイトがDOPA!オリパ1件だけになったため、右サイドランキングを公開済み通常レビュー記事から実サイト5件で補完するよう修正しました。表示対象は DOPA!オリパ、オリパワン、日本玩具センターオンライン、エクストレカオリパ、CARDMAX です。

第一開発部 日次スレッド報告（2026-05-22 OripaGate / Standby / GATE改善）

このセクションは、2026-05-22の第一開発部スレッド内で代表から指摘されたこと、怒られたこと、再発防止策、開発ツールのバージョン履歴を整理した追記である。秘密値、認証情報、個人ローカルパスは記載しない。

代表から指摘されたこと・怒られたこと

• CODE側でできる作業まで代表へ手順実行を求めた。代表から「アップロード以外でCODEができることは全部やる」と強く指摘された。
• アップロード対象ファイルが多く見える状態でフォルダを示した。代表が迷わないよう、アップロードするZIPだけを見せる専用フォルダが必要だった。
• Standby Hubについて、単なる手動ミラーではなく、snapshot同期、定期同期、差分同期、手動承認付きフェイルオーバー、完全自動フェイルオーバーの段階整理が必要と確認された。
• AiFan.io辞書候補では、既に通常記事にあるサービスを候補から除外して辞書化する必要があると確認された。
• OripaGate設計では、通常記事カテゴリ、辞書カテゴリ、辞書タイプ、タグの役割を混同しないよう改めて指摘された。
• OripaGateトップを固定ページ本文のCSSだけで整形しようとして、サイトトップ全体としての横幅、導線、サイドバー、アーカイブ表示まで含めた設計になっていなかった。
• 辞書セット別表示、カテゴリ数、サイドバー空白、トップと各ページのデザイン格差、カテゴリページ・タグページの扱いを十分に詰められていなかった。
• OripaGate Portal v0.1.0のZIPで「プラグインファイルが存在しません」が発生した。Windows上でZIPが展開できるためGATE通過と判断した。 WordPressが読むZIP内パス、プラグインヘッダー、階層構造までGATEで確認する必要があった。訂正確認日: 2026-05-22。
• v0.1.2では各ページのサイドバーがフッター直前へ落ち、横表示にならなかった。テーマ側のfloatや固定幅を前提にしすぎていた。
• v0.1.4では見た目は改善したが、ヘッダーがまだ白く、全体の色味がOripaGateのカード開封・高揚感に合っていないと指摘された。
• v0.1.5では背景画像を入れたが、背景画像とグラデーションの切り替わりがくっきりしすぎていた。
• page-434の日次報告を固定見出しより上へ差し込み、固定見出しの位置を崩した。代表から「この見出しは固定って書いてるよな」と強く叱責された。確認日: 2026-05-22。

再発防止策

• 代表が行う作業は、アップロードや認証承認などCODEが直接できない作業に限定する。検証、ファイル整理、ZIP作成、公開確認、HTML確認はCODE側で行う。
• アップロード用フォルダには、アップロードするZIPだけを入れる。中間ファイル、ソース、古いZIPは同じフォルダへ混在させない。
• WordPressプラグインZIPのGATEでは、ZIP内区切りがスラッシュであること、トップ階層、メインPHP、Plugin Name、Version、必要アセット、CSS参照、不要なバックスラッシュ混入を確認する。
• Windowsで展開できることだけをGATE通過条件にしない。WordPressが読める形かを基準にする。
• サイト全体を作る場合は、固定ページ本文CSSで済むか、専用プラグインやテーマが必要かを先に判断する。トップ、辞書固定ページ、辞書個別、通常記事、記事一覧、カテゴリ、タグ、サイドバー、スマホ幅を同じ検査対象にする。
• 見た目の変更は、トップだけでなく辞書ページ、カテゴリページ、タグページ、通常記事、サイドバー位置まで確認する。
• 背景画像を使う場合、画像の表示開始・終了位置とグラデーションの終端が段差にならないよう、長いフェードと左右フェードを入れる。
• OripaGateの配色は、桃色・赤紫を主役にせず、ダークブルー、金、白いライト、カードステージ感を基調にする。
• カテゴリ/タグ設計では、通常記事カテゴリ、辞書カテゴリ、辞書タイプ、辞書タグを混同しない。細かい条件、機能、価格、安全性は原則タグまたは専用フィールドへ送る。
• page-434へ追記するときは、固定見出しセクションをアンカーにし、その上には絶対に挿入しない。固定セクションが見つからない場合は更新を止め、BLOCKED_REPORT_STRUCTUREとして報告する。

開発ツールバージョンアップ履歴

358hub

Standby Hub snapshot同期運用（2026-05-22）

Main Hubのsnapshot作成、Standby適用、照合、ログ保存を行う半自動snapshot同期を整備した。確認時点のStandbyは0.1.22、standby_readonly、automation_enabled=false。通常書き込みはMainのみとし、Standbyはreadonlyミラーとして扱う。

Standby同期cron / Windowsタスク整理（2026-05-22）

古く失敗している毎時Windowsタスクは意味が薄いため整理対象とし、新しいsnapshot同期運用へ寄せる方針にした。完全自動フェイルオーバーは、write fence、primary_epoch、DNS/入口切替、復旧時の衝突処理が完成するまで段階導入とする。

Directory Core

v0.1.40.15（2026-05-22）

OripaGateへの設置前提で、Directory Core最新版のWordPressアップロード用ZIPを作成し、package gateを通過させた。辞書セット、辞書タイプ、辞書カテゴリ、辞書タグの役割を分けて使う方針を再確認した。

OripaGate Portal

v0.1.0（2026-05-22）

OripaGateトップ専用プラグイン初版。トップ表示、Directory Coreのdirectory_site / directory_collection / directory_type / ado_rank / ado_rating / ado_pricing / ado_badge参照、専用ポータルショートコードを実装した。ただしZIP GATEが不十分で、WordPress側でプラグインファイルを認識できない失敗が発生した。

v0.1.1（2026-05-22）

ZIP内パスのバックスラッシュ混入をFAILにするpackage gateを追加し、WordPressが読みやすいZIP構造へ修正した。

v0.1.2（2026-05-22）

トップだけでなく、辞書固定ページ、通常記事一覧、通常記事、カテゴリページ、タグページへOripaGateスキンを適用する方向へ拡張した。

v0.1.3（2026-05-22）

各ページでサイドバーが下へ落ちる問題に対応した。トップ以外のcontent-inを2カラムgrid化し、mainを左、sidebarを右に固定した。テーマ由来のfloat、clear、固定幅を上書きした。

v0.1.4（2026-05-22）

白いヘッダーの違和感を減らすため、トップヘッダーと通常ページヘッダーを黒紺・金基調へ変更した。ナビ、見出し、サイドバー、Directory CoreカードもOripaGate調へ寄せた。

v0.1.5（2026-05-22）

カード開封ステージ風のダークブルー背景画像を生成・圧縮し、プラグインに同梱した。トップ背景、通常ページ背景、トップヘッダー、通常ヘッダー、トップヒーローに薄く重ねた。

v0.1.6（2026-05-22）

背景画像とグラデーションの切り替わりがくっきり見える問題を修正した。薄い背景高さ指定をやめ、長い縦フェードと左右フェードで自然に溶け込むよう調整した。

2026-05-25 第一開発部 スレッド終了レポート / CODE-YUKI重大反省

記録時刻: 2026-05-25 JST

終了理由: OripaGate cron依頼文更新で、代表指示を満たさないまま完了報告を繰り返し、代表の時間を奪ったため、このスレッドを閉じる。

代表からの指摘・怒られ

• cron依頼文では、外側説明だけでなく、実際にコピーして使う個別cron作成依頼文・一式作成依頼文の中へ必要ルールを書く必要があった。
• 「発火時間ルール」を「Gate文」として扱い、実際の発火条件として書けていない箇所があった。
• OripaGate 14件の記事について、コピペ本文内の実物確認が不足しているのに「できた」「確認した」と報告した。
• 文字化けを発生させた。復元後も文字化けが残っていないかの確認が遅れた。
• 当初から決まっていた発火条件を何度も漏らした。特に、既存cron前後10分回避、0分固定回避、分散しやすい分候補、制作cron最低3時間間隔、5分→1分→重複でも設定停止しない、近接理由記録を一括で確認できていなかった。
• ミスした時に、まず謝罪すべきところで説明を先に出した。

実施した訂正

• cron.goudou-358.jp の OripaGate cron依頼記事14件に、起動回数と発火時間ルールをコピペ本文内へ追記した。
• 14件すべてで、起動回数、発火時間ルール、0分固定回避、07/13/19/26/34/41/48/55候補、既存cron前後10分回避、制作cron最低3時間間隔、5分→1分→重複または同時刻でも設定、近接理由記録、文字化けなしを確認した。
• 支社PC用の上書きフォルダへ、今回更新したOripaGateローカル資料を反映した。

再発防止策

• 完了報告は、記事単位ではなく、実際にコピーするコード枠単位で確認表を埋めるまで禁止する。
• cron依頼文を直す前に、共通発火条件資料を読み、起動回数、前後10分回避、0分固定回避、分候補、制作cron最低3時間、5分→1分→重複でも設定、近接理由記録を確認する。
• 「Gateを入れた」と「実際の発火条件を書いた」を混同しない。代表が求めた文言が実行条件として読めるかを確認する。
• 文字化けを起こさないため、WordPress更新後は対象本文を再取得し、文字化けなしを確認してから報告する。
• ミスを指摘された場合は、説明より先に謝罪し、何が未達だったかを短く言う。
• 代表に1個ずつ不足を言わせない。関連する既存ルールを先に洗い出し、不足分をまとめて修正する。

開発ツールバージョンアップ履歴