wjs-auditing-project

wjs-auditing-project

概要

プロジェクトの状態を包括的に監査します。停滞しているもの、壊れているもの、計画から逸脱しているものをすべて見つけ、チェックリストをユーザーに確認した後でまとめて修正します。

厳守する二段階の分離：

1. 調査 → 項目ごとに分類したチェックリストを提示（読み取り専用。コミット、マージ、プッシュは禁止）
2. 修正 — ユーザーが実行する内容を明示的に確認した後に限ります

フェーズを決してまとめないでください。ユーザーは、何らかの作業を行う前に全体像を確認したいと考えています。「そのまま全部直してください」という指示でも確認としては問題ありませんが、まず一覧できるようにチェックリストを提示してください。

使用するタイミング

• 「看看现在的项目到底出了什么问题」／「make it right」／「what's broken」
• 「为什么我的反馈还没上线」
• 「为什么很久没有新 build / 没提交 App Store」
• 「有没有 PR / 分支没合」
• しばらく離れていたプロジェクトに戻るとき
• リリース／TestFlight へのプッシュ前に、未処理の項目が残っていないか確認するとき

フェーズ 1 — 調査（並列実行）

読み取り専用のチェックをすべて、並列の Bash 呼び出しを使って1つのメッセージ内で実行します。どれを実行するかユーザーに尋ねず、すべて実行してください。「問題なし」という結果が多くても問題ありません。その項目はチェックリストに表示されません。

A. 作業ツリーと stash

• git status — 未コミットの作業はありますか？
• git stash list — 忘れられた stash はありますか？
• git branch -vv — ローカルブランチと、追跡先に対する先行／遅れの状況
• git log --oneline main..HEAD — 現在のブランチにあり、main にないもの
• git fetch origin --prune && git log --oneline HEAD..@{upstream} — リモートにあり、ローカルにないもの
• git branch -r --merged main と git branch -r --no-merged main — リモートに残っている未処理のブランチ

B. オープン／ドラフト PR

• gh pr list --state open --json number,title,isDraft,mergeable,mergeStateStatus,updatedAt,author,headRefName
• 7日を超えている PR、または mergeStateStatus ≠ CLEAN の PR について、gh pr checks <num> で失敗したチェックを取得します
• 自動マージ対象のボット PR（メモリに基づく：アプリ内フィードバック → @claude PR → 自動マージ）：gh pr list --author "app/claude" --state all --limit 20 — マージ済みでまだ TestFlight ビルドに含まれていないものはありますか？オープンのまま停滞しているものはありますか？

C. CI／GitHub Actions

• gh run list --limit 20 --json conclusion,name,headBranch,createdAt,databaseId,event
• gh run list --status failure --limit 10 — 失敗した実行に絞り込みます
• main またはオープン PR のブランチで失敗した実行ごとに、gh run view <id> --log-failed | tail -100 を実行し、実際のエラーを取得します

D. リリース済み作業と未リリース作業（Cathier の iOS 固有項目）

• grep -E "MARKETING_VERSION|CURRENT_PROJECT_VERSION" *.xcodeproj/project.pbxproj | sort -u — 現在のバージョンとビルド番号
• git tag --sort=-creatordate | head -5 — 最近のリリースタグ
• git log --oneline <last-tag>..main — 最後にタグ付けされたリリース以降のコミット
• fastlane/ の設定と fastlane/report.xml（存在する場合）を確認し、最後の pilot／deliver の実行を確認します
• git log -1 --format="%ai %s" -- fastlane/ — fastlane の最終変更
• git log --all --grep="bump\|version\|build" -10 --oneline — 最近のバージョン更新

E. 計画とのずれ

• TODOS.md、CHANGELOG.md、APP_STORE_SUBMISSION_GUIDE.md、ROADMAP.md、docs/plan*.md があれば読みます
• 計画項目とリリース済みコミットを照合します。記載されているものの未完了の項目はありますか？すでに過ぎた日付が設定されている項目はありますか？
• grep -rn "TODO\|FIXME\|XXX" --include="*.swift" . — ソース内の計画とのずれを示すマーカー

F. アプリ／システムログ

• ls -t ~/Library/Logs/DiagnosticReports/Cathier* 2>/dev/null | head -5 — アプリの最近のクラッシュレポート
• log show --predicate 'process == "Cathier"' --last 1d --style compact 2>/dev/null | grep -iE "error|fault" | head -20 — 最近の実行時エラー（この Mac にインストールされていない場合は、何も表示せずスキップします）
• ls -t ~/Library/Developer/Xcode/DerivedData/*/Logs/Build/*.xcactivitylog 2>/dev/null | head -3 — 最後のビルド試行（存在と更新日時のみ。解析はしません）

G. ユーザーフィードバックについて

メモリによると、アプリ内フィードバックから @claude の PR が作成され、自動的に main にマージされます。「アプリにフィードバックが反映されていないのはなぜですか？」に答えるには、次を確認します。

1. フィードバックから PR が作成されましたか？（gh pr list --author "app/claude" --state all）
2. マージされましたか？（PR のステータスを確認）
3. マージコミットより新しい TestFlight／App Store ビルドがありますか？ 3 が「いいえ」なら、それが答えです。main にマージされましたが、ビルドも提出もされていません。

チェックリストの提示

グループ分けした Markdown チェックリストを1つ出力します。各項目には、問題点、根拠（数値／日付／ファイルパス）、ユーザーが「はい／いいえ」で回答できるように提案する対応を含めます。緊急度ごとにグループ分けします。

## What I found

### 🔴 Blocking (these gate everything else)
- [ ] PR #42 "Add jokes redesign": 3 failing checks (SwiftLint, build, tests). Last commit 2026-04-30. → Read logs, fix, push?
- [ ] main is 7 commits ahead of last tag v1.4.0 (2026-03-22). No TestFlight build since then. → Tag v1.5.0 and prep release notes?

### 🟡 Open work
- [ ] Local branch `home-simplification` has 5 commits, no open PR, last activity 2026-05-08. → Open PR against main?
- [ ] Stash "WIP: brain trainer stats" from 2026-04-02. → Show diff and decide drop/apply?

### 🟢 Plan drift (TODOS.md / fastlane)
- [ ] TODOS.md line 14: "Submit App Store build by 2026-04-30" — overdue 11d, no `fastlane pilot` invocation since 2026-03-12.
- [ ] TODOS.md line 22: "Hook up haptics on streak page" — no matching commit on main.
- [ ] 2 auto-merged @claude PRs (#88, #91) from in-app feedback merged after last TestFlight build — user feedback shipped to main but not to TestFlight.

### Logs / errors
- [ ] 23 errors in last 24h matching "NSURLErrorDomain -1009" (offline path) — investigate or note as expected?
- [ ] 1 crash report from 2026-05-10 in DiagnosticReports — pull stack and triage?

### Looks fine
- Working tree clean, no orphan branches on origin, no failed CI on main this week.

最後に、次の文を付けます。「これらをすべて修正しますか？それとも一部を選びますか？あるいは、まずどれかについて話し合いますか？」

フェーズ 2 — 修正（ユーザーの確認後のみ）

ユーザーが（すべて、一部、または「App Store の項目以外で、緑と黄色の項目をすべて」）確認したら：

1. 確認済みの項目ごとに ToDo を TaskCreate で作成します
2. 順序：CI の失敗 → ブランチのマージ → タグ → バージョンの更新 → リリースノート → ビルドの依頼
3. 一度に 1 項目ずつ対応し、まとめてではなく、完了したらすぐに完了としてマークします
4. 各修正後、フェーズ 1 の該当するチェックを再実行して、実際に解決したことを確認します
5. 最後に、修正済み／スキップ／人による対応が必要、という簡潔なまとめを出します

自律的に対応できること

• 失敗した CI ログを読み、コードを編集して、修正をプッシュする
• 未プッシュのブランチに対して gh pr create で PR を作成する
• 失敗の原因を診断した後、失敗した実行を gh run rerun <id> で再実行する（不安定に見える失敗をむやみに再実行せず、まず根本原因を突き止めます）
• ユーザーがその PR について承認した場合、問題のない PR を gh pr merge --squash --auto でマージする
• project.pbxproj の MARKETING_VERSION／CURRENT_PROJECT_VERSION を更新する
• CHANGELOG の項目を追加し、git tag でリリースにタグを付ける（ユーザーの確認があるまでタグはプッシュしません）
• 差分を表示した後、スタッシュを破棄または適用する

ユーザー自身の操作が必要なこと

先頭に ! を付けて、実行すべきコマンドを正確に表示します。

• ! fastlane pilot upload — App Store／TestFlight への提出ではバイナリへの署名が必要なため、ユーザー自身の操作が必要です
• ! open Cathier.xcodeproj — Xcode のアーカイブ用 UI が必要な操作
• 破壊的な操作：git reset --hard、git push --force、ブランチの削除

よくある調査結果 → 標準的な修正

調査結果	標準的な修正
ローカルブランチが main より先行しており、PR がない	main をリベースしてプッシュし、gh pr create を実行する
同じステップで PR の CI が 2 回失敗している	失敗ログを読み、根本原因を修正する。むやみに再実行しない
未リリースのコミットがあり、TestFlight が古い	ビルド番号を更新し、タグを付け、リリースノートを書き、ユーザーに fastlane pilot の実行を依頼する
30 日を超えたスタッシュがあり、内容が不明	git stash show -p <n> をユーザーに表示し、破棄するか適用するか尋ねる
TODOS.md にコミットされていない項目がある	ユーザーに伝える。スコープ外になったのか、忘れられているのか？決めつけない
最後のビルドより新しい、自動マージ済みのフィードバック PR がある	必要なのはコードの追加変更ではなく、新しい TestFlight ビルドです
計画では App Store の締め切りが過ぎているのに、fastlane/ が変更されていない	締め切りと最後の提出日を伝え、優先順位はユーザーに判断してもらう

危険信号 — 停止

考え	実際には
「チェックリストを省略して、すぐに修正しよう」	いいえ。ユーザーは監査してから確認を得る手順を明確に求めています。
「この PR はマージしても安全そうだから、マージしよう」	返信でこの PR を名前を挙げて確認した場合に限ります。
「履歴を整理するために、強制プッシュしよう」	操作ごとの明確な確認なしに実行してはいけません。
「停止中の PR を閉じて整理しよう」	まず調査します。作業を救済できる可能性があります。
「ユーザーに代わって App Store に提出しよう」	絶対にしてはいけません。! fastlane … コマンドを表示して停止します。
「クラッシュレポートはおそらく問題ない」	スタックを取得してユーザーに提示します。判断はユーザーに任せます。
「計画項目が古いから、もう不要だろう」	尋ねます。計画の項目を削除してはいけません。

このユーザー／Cathier 固有の注意事項

• デフォルトの作業ディレクトリ：/Users/jianshuo/code/Cathier。どこから呼び出されても、これを尊重してください。
• Cathier は、App Store／TestFlight 向けの fastlane/ を備えた SwiftUI iOS アプリです。
• 計画の正本は TODOS.md と APP_STORE_SUBMISSION_GUIDE.md にあります。両方を読んでください。
• メモ：アプリ内フィードバック → app/claude が PR を作成 → main に自動マージされます。そのため、「フィードバックがアプリに反映されない」場合は、通常、マージは完了したものの、新しいビルドが作成されていないことを意味します。コードを調査する前に、TestFlight のビルド日時と PR のマージ日時を確認してください。
• gh は認証済みです。fastlane はインストール済みです（Gemfile があります）。
• 見た目の正本は DESIGN.md です。矛盾する UI の修正は、指摘せずに提案しないでください。