Improve app

1. $improve-app と同じメッセージに書かれた内容を今回の改善依頼として扱う。
2. 依頼が短い場合は docs/product/backlog.md、Issue、利用ログ、未完フロー、テスト失敗を読み、影響度・頻度・依存・リスクから最有力の1件を選ぶ。候補一覧を返して選択待ちにしない。
3. 複数要望は内部で分割・採点し、今回進める縦切り1件を確定する。残りは理由つきで残課題へ置く。
4. catalog-default入口契約: 依頼文の「デザイン」「見づらい」等の語ではなく、実際の変更予定で判定する。DOM/JSX/HTML、描画component、通常の新画面追加、layout、style/token、利用者が操作するinteractionのいずれかを作る・変えるなら jp-web-design の references/catalog-default-contract.md を適用対象として委譲する。可視UIへ一切触れない場合だけ NON_VISUAL(理由) を渡す。適用・証跡・検査の詳細は同契約だけを正本とする。
5. Cloudflare MCP の user scope 登録と wrangler 実行はエージェントが代行する。OAuth 認証と git 管理外の .mcp.json だけ本人が行う(INV-11)。codex mcp get <name> --json で docs / bindings / observability を確認し、未登録・不通・明示的な legacy type:sse なら codex mcp remove <name> の後 codex mcp add <name> --url https://<name の製品名>.mcp.cloudflare.com/mcp を自分で実行する。/mcpを推奨するが、/sse URLがStreamable HTTP互換aliasとして動作する場合はそれだけで移行しない。legacy SSE GETが410になるtype:sseだけを移行対象とする。既存アプリでは登録が後から壊れていることがあり、ここで見ないと誰も直さない。今回の改善がbindings変更またはobservability調査を必要とし、その対象が認証待ちのときだけ、対象1件のブラウザ認可(codex mcp login <name>)を依頼する。未使用MCPの認証は求めず、承認を待たずに次へ進む。
6. 成熟度を複数の信号で判定する。まず git fetch --tags --prune を試み(オフライン・権限不足で失敗しても判定を続ける)、次を読む。
   • release tag: exact v1、v1.*、またはそれ以降の明示的release tag
   • project marker: T4 の v1 Go・受入確認、またはプロジェクトの正本にある明示的な stage: v1+ / 本番稼働マーカー(READMEの宣伝文は根拠にしない)
   • 安全運用信号: デプロイ用workflowまたはWorkers Builds、production Environment、default branch保護、PR運用のいずれか
7. exact v1 / v1.* / 以降のrelease tag、または明示的な v1+ project marker があれば app_orchestrator へ「追加開発モード・成果物先行」で委譲する。main 直反映を許すのは、新規AIDDプロジェクトで、T2/T4等の正本が pre-v1/v0 を明示し、上記の安全運用信号と矛盾しない場合だけ。その場合は「v0→v1 の育てるループとしてステージ3-B・6、main 直反映」と委譲する。既存repoで判定に確信がない、fetchできない、または信号が矛盾する場合は安全側のブランチ + PRとし、main に直接反映しない。いずれもcatalog-default判定を含めて渡し、完了まで待つ。利用できないクライアントでは現在のスレッドで $app-orchestrator を使用して完遂する。
8. v1+または判定不確実ならブランチ作成からpreview/PRまで、明確な新規pre-v1 AIDDだけ main 直反映とpreviewまで自律的に進め、依頼者には成果物への差分を求める。公開・マージなど権限境界は既存の承認規律を守る。
9. 最終報告は、今回できるようになったこと、試してほしい操作、採用理由、更新後の残課題、次に自動選定した候補の順で書く。可視UIを変更した場合はcatalog-default判定結果だけを1行添える。git用語は使わず、app-orchestrator の語彙対応表に従う。