スロット攻略 プロジェクトドキュメント

Appearance

コマンド一覧 ​

プロジェクトで利用するコマンドを一覧にまとめています。ツールの概要・設定は ツール概要・設定 を参照してください。

このページは ローカル実行コマンドの正本 です。CI をいつ走らせるかは CI 運用方針、各テストツールの使い方は テスト・品質確認ガイド、PHPCS / PHPStan などの設定理由は 品質設定ドキュメント を参照してください。

CI 運用の重要ルール ​

  • CI Quality Gate は PR 作成時などに 1 回実行します。
  • 追加 push 後は自動起動しません。
  • マージ前の最新コミット検証は Actions → CI Quality Gate → Run workflow（pr_number または PR ブランチ）を使います。
  • Re-run all jobs は旧 SHA の再実行であり、追加 push 後の検証には使いません。

CI ワークフローとローカルコマンド対応 ​

ワークフロー名内容ローカルで再現するコマンド
PHPCS CheckWordPress Coding Standards・未使用use文・PHPCScomposer lint / composer lint-fix
PHPStan Check静的解析composer phpstan-ci
Deptrac Architecture Checkアーキテクチャ依存関係チェックcomposer deptrac
PSR-4 Compliance CheckPSR-4 準拠チェックcomposer psr4
Format CheckPrettier フォーマットチェックnpm run format:check / npm run format
JavaScript LintESLintnpm run lint:js
CSS LintStylelint（CSS 構文・明らかなミス）npm run lint:css
TypeScript Type CheckTypeScript 型チェック（tsc --noEmit）npm run typecheck
jscpd重複コード（閾値超過で fail）npm run duplicates:check
Shell Lint（shellcheck）Bash 静的検査（bin/ + 主要 scripts/）composer shellcheck

CI の起動条件、手動実行の入力、レビュー時に避けるべき提案は CI 運用方針 と CI Quality Gate を参照してください。

複数チェックをまとめて実行する例:

  • PHPStan（core_src + tests）+ Deptrac: composer ci-static-check
  • 品質一括（PHPCS + PHPStan（core_src + tests）+ PHPUnit）: composer quality

PHP 系ワークフローでは、core_src で composer install によりオートロードが生成されます。背景は Composer Autoload 運用ガイド を参照してください。

PHPCS（コーディング規約） ​

composer lint / lint-fix は connector.php・core_src・config のみを対象とします。リポジトリ全体を走査すると CI で OOM になるためです。tests/ は composer lint-tests / lint-tests-fix、その他（scripts/・myTemplate/ 等）は composer run lint-path -- <パス> で個別に実行してください。

用途コマンド
チェック（サマリ）composer lint
テストコードのみcomposer lint-tests
テストコード自動修正composer lint-tests-fix
チェック（詳細）composer lint-verbose
特定パスのみチェックcomposer run lint-path -- <パス>
詳細レポートcomposer lint-full
ソース表示レポートcomposer lint-source
自動修正composer lint-fix
特定パスのみ自動修正composer run lint-fix-path -- <パス>
Checkstyle 出力composer lint-report
進捗確認composer lint-progress

PHPStan（静的解析） ​

composer analyse / phpstan-ci には shipmonk/dead-code-detector による未使用メソッド検知が含まれます。既存候補は config/phpstan-baseline.neon に記録し、新規追加分のみをブロックします。WordPress フック由来の誤検知対策は config/phpstan/WordPressHookEntrypointProvider.php を参照してください。

運用上の注意:

  • 新規の未使用メソッドは原則ベースラインに追加せず、削除するか EntrypointProvider / 呼び出し参照の修正で対応する。
  • PHP-DI 向けに Unused ...::__construct を ignoreErrors しているため、コンストラクタ内だけで参照される伝達的デッドコードの tip は見えなくなる。将来は DI 登録クラスの __construct を Entrypoint 化し、この ignore を狭める余地がある。
  • ベースライン再生成（既存分の洗い替えが必要なときのみ）:
bash
vendor/bin/phpstan analyse --memory-limit=4G --configuration=config/phpstan.neon --generate-baseline=config/phpstan-baseline.neon
  • 削減時は Interface 契約・Entity/DTO getter・*_for_tests・真のデッドコードを分けて見直し、テスト専用は本番コードから外すか @phpstan-ignore へ寄せる。
用途コマンド
解析（推奨）composer analyse
CI 同等（core_src）composer phpstan-ci
CI 同等（tests）composer phpstan-tests
メモリ増量時composer analyse -- --memory-limit=6G

composer phpstan-tests は tests/Unit 専用の設定 config/phpstan-tests.neon（level 0、baseline なし）で、config/phpstan/Rules/ の独自ルールを当てます。composer ci-static-check と CI Quality Gate の「Run PHPStan (tests)」でも実行されます。現在のルールは次のとおりです（書き方の詳細は PHPUnit テスト実行ガイド > 書かないテスト）。

  • NoExistenceAssertionRule（identifier: slotKouryaku.testExistenceAssertion）: assertTrue(method_exists(...)) / class_exists / interface_exists による存在確認だけのアサーションの禁止
  • NoConstantCopyAssertionRule（identifier: slotKouryaku.testConstantCopyAssertion）: assertSame / assertEquals でリテラル（スカラーと、要素がすべてリテラルの配列リテラル）とクラス定数（Foo::BAR）を比べるだけのアサーションの禁止。直前の行に日本語の理由コメント（記号・空白を除いて 10 文字以上）があれば許可
  • SeparateProcessReasonRule（identifier: slotKouryaku.testSeparateProcessWithoutReason）: #[RunInSeparateProcess] / #[RunTestsInSeparateProcesses] に「別プロセス」「別のプロセス」「プロセス分離」「プロセスを分離」「プロセスを分ける（分けて）」のいずれかを含む日本語の理由コメントがないものの禁止

Rector（デッドコード候補） ​

SetList::DEAD_CODE を rector.php で導入しています（CI 必須化はしない）。Issue #3237（不要 PHPDoc タグ・不要キャスト・SimplifyUselessVariable・AlwaysTrue/False・DeadInstanceOf）および Issue #3248（RemoveDeadReturn・RemoveUnusedVariableAssign、未使用 private/promoted property のクラス単位有効化）は適用済み。未構築 WIP Entity は #3255 で削除し、RemoveUnusedPrivateProperty の path skip は残していない。残 skip は RemoveUselessVarTagRector と RecastingRemoval / AlwaysTrue の path skip。

用途コマンド
候補確認（dry-run）composer rector または mkdir -p reports && composer rector 2>&1 | tee reports/rector-dead-code.txt
適用（要レビュー後）composer rector-fix

Deptrac（アーキテクチャ） ​

用途コマンド
解析composer deptrac
CI 同等composer deptrac-ci

PSR-4 準拠 ​

用途コマンド
チェックcomposer psr4
CI 同等composer psr4-ci

フォーマット（Prettier） ​

用途コマンド
全ファイル整形npm run format
チェックのみnpm run format:check
特定ファイルnpx prettier --write <パス>

JavaScript Lint（ESLint） ​

用途コマンド
全体チェックnpm run lint:js
自動修正つきnpx eslint "**/*.{js,jsx,mjs,cjs}" --fix

eslint.config.cjs を正本とし、@wordpress/scripts 経由で ESLint を実行する。pre-commit の lint-staged ではステージされた JS ファイルに eslint --fix と Prettier を適用し、CI Quality Gate でも npm run lint:js を実行する。TypeScript は tsconfig.json を正本に npm run typecheck で検査する。

CSS Lint（Stylelint） ​

用途コマンド
全体チェックnpm run lint:css

stylelint.config.cjs を正本とし、core_src/**/*.css・myTemplate/**/*.css・mockups/**/*.css・docs/**/*.css を対象に検査する。*.min.css、ビルド出力、docs/.vitepress/dist/ は対象外。既存 CSS への大量ノイズを避けるため、導入時点では CSS 構文エラー、重複プロパティ、未知プロパティ、未知単位など明らかなミスを検出する最小ルールから開始する。CI Quality Gate でも npm run lint:css を実行する。

Shell Lint（shellcheck） ​

用途コマンド
全体チェックcomposer shellcheck
CI 同等（エイリアス）composer shellcheck-ci
ラッパー直接実行./bin/run_shellcheck.sh

bin/*.sh 全ファイルと、デプロイ・DB 同期・バックアップ等の主要 scripts/*.sh（対象一覧は bin/run_shellcheck.sh）を shellcheck で静的検査する。意図的なパターン（SSH 先での展開、動的 source など）は理由付きの # shellcheck disable= コメントで抑制する。

前提: ローカルでは brew install shellcheck などで PATH に入れる。CI（ubuntu-latest）は runner にプリインストール済み。CI Quality Gate でも軽量ステップとして実行する（Plan B の統合ゲート内。毎 push 起動はしない）。

TypeScript（型チェック） ​

用途コマンド
型チェックのみ（ビルドなし）npm run typecheck

tsconfig.json を正本とし、core_src/**/*.ts(x)・tests/**/*.ts(x)・vitest.config.ts を対象に tsc --noEmit を実行する。型エラーはゼロを維持する方針で、CI Quality Gate にも組み込まれている（mockups/・docs/.vitepress/ は対象外）。

Vitest（フロントエンド） ​

用途コマンド
Vitest のみnpx vitest run
通し（build + Vitest + DBML）npm test

コロケートの *.test.{ts,tsx,js} を対象にする。詳細は Vitest 実行ガイド。CI Quality Gate の Run Vitest ステップでも npm run test が実行される。

PHPUnit（テスト） ​

用途コマンド
全テスト実行composer test
特定テストvendor/bin/phpunit tests/Unit/ path/To/Test.php
カバレッジレポートcomposer test-coverage

まとめて実行 ​

用途コマンド
PHPStan + Deptrac（CI 同等）composer ci-static-check
PHPCS + PHPStan + PHPUnitcomposer quality
PHP 静的品質チェック（PHPCS + PHPStan + Deptrac、PHPUnit なし）composer quality-check または ./bin/run_local_quality_check.sh
CI Quality Gate 相当の一括（ローカル再現）composer quality-check:full または ./bin/run_ci_quality_gate_local.sh
Composer audit（root）composer audit
Composer audit（core_src）composer audit:core
Composer audit（root + core_src）composer audit:all
npm audit（本番依存・high 以上で fail）npm run audit
npm audit（dev 含む・CI 対象外）npm run audit:all
依存 audit 一括（Composer + npm 本番・CI と同内容）composer dependency-audit または ./bin/run_dependency_audit.sh
jscpd レポートnpm run duplicates
jscpd ゲート相当（閾値超過で fail）npm run duplicates:check
jscpd tests/Unit の重複（表示のみ。CI 対象外）npm run duplicates:tests

CI ゲートの手順・個別コマンド対応表の正本: CI 運用方針。quality-check は PHP 静的のみ。PHPUnit / format / lint / typecheck / Vitest / build / jscpd まで含めるときは quality-check:full を使う。COMPOSER_NO_AUDIT=1 により install 時の自動 audit は無効で、代替は上記の明示 audit。

ビルド・デプロイ・ドキュメント ​

用途コマンド
古いローカルビルド削除./bin/clean-old-builds.sh
古いリモートビルド削除（本番）./bin/clean-remote-builds.sh
古いリモートビルド削除（ステージング）./bin/clean-remote-builds-staging.sh
本番ビルド./bin/build.sh（要 LEGAL_OPERATOR_NAME / LEGAL_PUBLIC_CONTACT_EMAIL）
法務事業者情報をビルド成果物へ埋め込み（build.sh から自動呼び出し）./bin/embed-legal-operator.sh <core_dir>
ローカル用 LegalOperatorBuildValues.local.php 生成./bin/generate-legal-operator-local.sh
本番デプロイ（一括）./bin/deploy-all.sh（対話確認、または CONFIRM_QUALITY_GATE=1 CONFIRM_STAGING_VERIFIED=1。詳細は 本番環境デプロイ）
本番アップロードのみ./bin/deploy.sh [version]
本番 VERSION 切り替え＋キャッシュ削除./bin/activate.sh <version>
本番キャッシュ削除のみ./bin/clear-cache.sh
ステージングデプロイ（一括）./bin/deploy-all-staging.sh
ステージングアップロードのみ./bin/deploy-staging.sh [version]
ステージング VERSION 切り替え＋キャッシュ削除./bin/activate-staging.sh <version>
ステージングキャッシュ削除のみ./bin/clear-staging-cache.sh
管理画面でビルド一覧/削除WordPress 管理画面 → ツール → ビルド管理
ドキュメント開発npm run docs:dev
ドキュメントビルドnpm run docs:build
ドキュメントプレビューnpm run docs:preview
管理画面 UI ビルド（日報ブロック・P-WORLD 画像キャプチャ・公開 Chart.js バンドル）npm run build

npm run build は webpack.config.js のエントリを core_src/PostType/daily_article/Admin/assets/build/ へ出力します。公開ショートコード向け Chart.js バンドル（period-kishu-samai-ranking.js / period-kishu-samai-ranking-snapshot.js / hall-samai-graph.js 等）も .gitignore 対象のため、デプロイ前にローカルでビルドしないと本番でグラフが描画されません。./bin/build.sh / ./bin/deploy-all.sh は内部で npm run build を実行します。

本番 DB をローカルへ同期 ​

本番の差枚・業務テーブル、必要なら日別記事投稿をローカルへ取り込む。操作の正本は データベース同期（本番→ローカル）。安全確認は DB 同期安全ガイド。

用途コマンド
フル同期（破壊的・ローカル全体上書き）./scripts/sync-db-from-production.sh
月次差分（業務テーブルのみ upsert）./scripts/sync-db-month-from-production.sh YYYY-MM
期間差分（両端含む）./scripts/sync-db-month-from-production.sh --from YYYY-MM-DD --to YYYY-MM-DD
上記 + 日別記事投稿（posts / postmeta）の部分コピー上記に --with-daily-article-posts
WHERE のみ確認上記に --dry-run
非対話上記に --yes

設定は config/local.env（PROD_DB_* / LOCAL_DB_* / DEPLOY_*）。初回・スキーマ変更時はフル同期、不足月や期間だけなら差分を優先する。

本番デプロイ前バックアップ（DB + サイトファイル） ​

ConoHa のファイルマネージャーで一式 zip を取ると 504 になりやすいため、サイト一式は SSH / rsync で取得します（デフォルト）。backups/ は .gitignore 対象です。

用途コマンド
デプロイ前に DB ダンプ + WP ルートのミラー + 復旧メモ./scripts/backup-before-deploy.sh
DB とメモのみ（ファイル rsync なし）./scripts/backup-before-deploy.sh --no-files
wp-content/uploads/ も含める（時間・容量増）./scripts/backup-before-deploy.sh --with-uploads
バックアップした DB を本番へ復元./scripts/restore-db-to-production.sh backups/<日時>/db.sql.gz

デフォルトのファイル取得では wp-content/uploads/ やキャッシュ等を .backup-rsync-excludes で除外します。

設定は config/local.env（DEPLOY_* / PROD_DB_* / DEPLOY_REMOTE_PATH）。WordPress ルートを固定で指定したい場合は任意で DEPLOY_REMOTE_WP_ROOT を設定します。復旧手順は各バックアップ内の ROLLBACK.md を参照。

デプロイと myTemplate / scripts: ./bin/deploy.sh / ./bin/deploy-staging.sh（内部で bin/_deploy-core.sh を実行）は _build/core_* に加え、次をリモートの DEPLOY_REMOTE_PATH 配下へ同期します。

  • myTemplate/single-daily-article-template.php … リポジトリルートにファイルがあるときのみ myTemplate/ へアップロード。無い場合は警告のみ（core_* の転送は完了）。
  • scripts/ … リポジトリ直下の scripts/ を rsync で DEPLOY_REMOTE_PATH/scripts/ に同期（wp eval-file 用の PHP 等。.DS_Store と *.bak は除外）。
  • 前提条件 … scripts/ の同期は rsync に依存します。ローカル環境・リモート環境の双方に rsync がインストールされている必要があり、どちらか一方でも未導入の場合はデプロイがエラー終了します。

--delete の挙動（運用注意）: rsync --delete により、除外されていない同期対象ファイルでローカルの scripts/ に存在しないものは、リモートからも削除されます。バックフィルなど一時スクリプトをリモートで実行した後にローカルから削除した場合、次の deploy.sh 実行でリモートからも消えることを意識してください。スクリプトが不要になったことを確認してからローカルで削除し、その後デプロイするのが安全な手順です。

なお、--exclude='.DS_Store' / --exclude='*.bak' を付けているため、これらの除外パターンに一致するファイルは --delete だけではリモートから削除されません。除外対象も含めて完全に揃えたい場合は、リモートで手動削除するか、実装側で --delete-excluded の採用を検討してください。

Web 直接アクセス対策: scripts/ には scripts/.htaccess（Require all denied）を同梱しており、Apache 経由のブラウザアクセスをブロックします。ただし nginx 等の場合は Web サーバー設定側で scripts/ への直接アクセスを遮断してください。

SSH が使えない緊急時や zip 転送で高速化したい場合は、本番では ./bin/deploy-all-ftps-zip.sh または ./bin/deploy-ftps-zip.sh <version>、ステージングでは ./bin/deploy-all-ftps-zip-staging.sh または ./bin/deploy-ftps-zip-staging.sh <version> を使用できます。config/local.env / config/staging.env の DEPLOY_FTPS_URL / DEPLOY_FTPS_USER / DEPLOY_FTPS_PASS / DEPLOY_FTPS_PUBLIC_URL を使い、FTPS で zip と一時 PHP レシーバーをアップロードして、HTTPS 経由でサーバー側展開と VERSION 切り替えを行います。scripts/ は削除同期され、古い core_* と前回失敗時の一時ファイルも成功時に掃除されます。詳細は 本番環境デプロイ と ステージング環境デプロイ を参照してください。

日別記事が環境で表示されないとき（確認手順） ​

ローカルでは表示できるがステージング等で一般ユーザー向けに本文がほぼ出ない場合の切り分け。該当環境の DB・ファイル・HTML を確認します。

post meta（レイヤー A） ​

  • 対象の daily_article 投稿 ID を決める。
  • wp_postmeta の kousatsu_date / halls が 非空の文字列か確認する（配列として保存されている・空文字のみ等だとテンプレート側で一般ユーザーには出力されない）。
  • テーブルプレフィックスは環境に合わせて読み替える。
sql
SELECT meta_key, meta_value
FROM wp_postmeta
WHERE post_id = ? /* 投稿ID */
  AND meta_key IN ('kousatsu_date', 'halls');

HTML とログ ​

  • ログアウト状態で記事 URL を開き、HTML ソースに DailyArticleTemplate 関連のコメントやバリデーション文言がないか確認する。
  • WP_DEBUG / WP_DEBUG_LOG を有効にできる環境では debug.log の [ERROR] DailyArticleTemplate や TemplateHooks のデバッグログを確認する。

DOM と台データ（レイヤー B） ​

  • 開発者ツールで、日別結果ショートコード由来のマークアップ（ランキング・ヒートマップ等）が DOM に存在するか確認する。本文枠がまったく無い場合はレイヤー A やテンプレート未配置を先に疑う。
  • 台データなどアプリ用テーブルに、該当する考察日・ホールのデータが揃っているか（DB インポート範囲・バッチの有無）。

テンプレートと VERSION ​

  • リモートの子テーマに myCustom/myTemplate/single-daily-article-template.php があるか（上記デプロイで myCustom/myTemplate/ に同期するか、手動で配置）。
  • リモートの connector.php の VERSION と、実際に存在する core_YYYYMMDD_HHMMSS ディレクトリが一致しているか。

Transient ​

  • 必要に応じ daily_article_template_ プレフィックスの transient を削除し、表示が変わるか確認する（DailyArticleTemplateDataService 経由のキャッシュ）。

古いビルドの削除 ​

_build/ 内に蓄積した古いビルドディレクトリ（core_YYYYMMDD_HHMMSS）を削除します。

用途コマンド
一覧表示./bin/clean-old-builds.sh --list
最新1件を残して削除（デフォルト）./bin/clean-old-builds.sh
最新 N 件を残して削除./bin/clean-old-builds.sh --keep N
指定バージョンを削除./bin/clean-old-builds.sh --version YYYYMMDD_HHMMSS
ドライラン（削除対象の確認のみ）./bin/clean-old-builds.sh --dry-run
ドライラン（最新2件残す場合）./bin/clean-old-builds.sh --keep 2 --dry-run

注意: ./bin/build.sh は実行のたびに _build/* を全削除してから新規ビルドするため、通常は core_* が1件のみ残ります。複数ビルドが存在する場合（手動コピーなど）に本コマンドを利用してください。

リモート（本番・ステージング）の古いビルド削除 ​

デプロイ先サーバーの DEPLOY_REMOTE_PATH 配下にある core_YYYYMMDD_HHMMSS を削除します。

用途本番コマンドステージングコマンド
一覧表示./bin/clean-remote-builds.sh --list./bin/clean-remote-builds-staging.sh --list
最新1件を残して削除（デフォルト）./bin/clean-remote-builds.sh./bin/clean-remote-builds-staging.sh
最新 N 件を残して削除./bin/clean-remote-builds.sh --keep N./bin/clean-remote-builds-staging.sh --keep N
指定バージョンを削除./bin/clean-remote-builds.sh --version VER./bin/clean-remote-builds-staging.sh --version VER
ドライラン（削除対象の確認のみ）./bin/clean-remote-builds.sh --dry-run./bin/clean-remote-builds-staging.sh --dry-run
ドライラン（最新2件残す場合）./bin/clean-remote-builds.sh --keep 2 --dry-run./bin/clean-remote-builds-staging.sh --keep 2 --dry-run

注意: アクティブに利用中の core_* を削除するとサイトが動作しなくなる可能性があります。削除前に、リモート環境の connector.php などで VERSION 定数を参照し、現在参照中のバージョンを必ず特定してください。

管理画面でのビルド管理 ​

WordPress 管理画面の ツール > ビルド管理 から、サーバー上の core_YYYYMMDD_HHMMSS を一覧表示・削除できます。

  • 稼働中のバージョン（VERSION が参照中の core_*）は削除不可
  • チェックボックスで選択したビルドを一括削除可能

min-repo HTML インポート ​

min-repo.com への自動スクレイピングは行わず、管理者が通常のブラウザで開いた ?kishu=all ページの HTML を貼り付けてローカル DB に取り込みます。管理画面: サイドバー → min-repo HTML インポート。

用途手順
HTML インポートブラウザで min-repo の ?kishu=all ページ HTML をコピー → 管理画面「HTML インポート」
CSV エクスポート管理画面「CSV エクスポート」→ 必要に応じて本番側の CSV インポートで反映
取込履歴管理画面下部「取込履歴」で直近 50 件を確認（監査・再確認用）

デプロイ後、管理画面に manage_options で一度アクセスすると、旧 Cookie / 転送認証用 wp_options（アプリパスワード等）がワンショット削除されます。取込履歴 option は残ります。PHP-DI キャッシュも削除してください。

本番で HTML インポート時に Forbidden が出る場合（ConoHa WAF） ​

本番（ConoHa WING）で「HTML からインポート」押下後に 閲覧できません (Forbidden access) が出る場合、SiteGuard WAF が POST 本文を XSS 等と誤検知している可能性が高いです（WordPress 未到達）。

  1. 管理画面の自動整形（テーマ実装）: 送信前にブラウザが差枚テーブル周辺の最小 HTML に整形します。ページ全体をそのまま貼り付けて問題ありません。
  2. WAF ログ確認: ConoHa コントロールパネル → サイト管理 → サイトセキュリティ → WAF → 該当時刻のログ（多くはクロスサイトスクリプティング検知）。必要なら「除外」（作業後も WAF は ON に戻す）。
  3. フォールバック: CSV エクスポート → 本番 CSV インポート。

関連ドキュメント ​