[Roadmap][2026-07-22] 残存セキュリティ・保守アラート・QA・Visual Evidence・Portfolio Health・Pages再監査を完了する

[ootakazuhiko]

目的

2026-07-22（Asia/Tokyo）時点の it-engineer-knowledge-architecture と、公開ポータルから参照される個別書籍リポジトリの状態を基準に、残存するOpen PR、セキュリティ／依存債務、自動保守アラート、QA検出漏れ、構成不整合、スクリーンショット、build warning、横断可視化、Pages再監査を依存順に完了する。

本Issueは、稼働中のCodex CLIセッションが全文を読み込み、clone、調査、Issue／PR、レビュー、CI、merge後確認、証跡、cleanupまで実行するための正本Runbookである。

関連ロードマップ

• [Roadmap][Post-#258] 書籍群の供給網・build契約・自動保守・内容鮮度・Pages運用を段階改善する #265 — Post-#258の供給網・build契約・自動保守・Pages運用
• [Review 2026-08-15][Pages] legacy managed runtimeとcustom deployment移行判断を全公開書籍で再評価する #271 — 2026-08-15のPages再監査
• [Roadmap][Content Remediation] #274の改善IssueをEthereum除外で順次実装する #275 — #274のContent Remediation（Ethereum除外）

既存Issueを重複作成しない。既存ロードマップの完了条件を満たした場合は、本Issueから証跡を反映してcloseする。

---

1. 監査開始時点

ポータル

• Open Issue: [Roadmap][Post-#258] 書籍群の供給網・build契約・自動保守・内容鮮度・Pages運用を段階改善する #265、[Review 2026-08-15][Pages] legacy managed runtimeとcustom deployment移行判断を全公開書籍で再評価する #271、[Roadmap][Content Remediation] #274の改善IssueをEthereum除外で順次実装する #275
• Open PR: 0
• 正本: docs/_data/catalog.json
• 公開メインライン: 41冊
• 関連独立英語書籍: 1冊
• 計画書籍: 7冊

個別書籍のOpen PR

開始時点で確認したOpen PR:

• itdojp/ethereum-learning-bootcamp#136
  • Hardhat 3 migrationとhigh脆弱性解消
• itdojp/BioinformaticsGuide-book#545
  • Biopython / PyYAML更新
• itdojp/BioinformaticsGuide-book#544
  • checkout / setup-node更新

実行時に状態を再取得し、既にmerged／closedの場合は重複作業を行わず、merge SHA、review、CI、Pages、本番確認を証跡化する。

個別書籍のOpen Issue

開始時点で確認した残存Issue:

Security / dependency

• ethereum-learning-bootcamp#135
• ethereum-learning-bootcamp#133
• ethereum-learning-bootcamp#134
• ethereum-learning-bootcamp#131
• ethereum-learning-bootcamp#132
• evidence-based-engineering-book#33

Scheduled maintenance

• practical-auth-book#173
• ai-testing-strategy-book#198

QA coverage / link correctness

• supabase-architecture-patterns-book#150
• kubernetes-proxmox-to-cloud-book#42
• IT-engineer-communication-book#143
• IT-engineer-communication-book#141

Structure / visual evidence

• podman-book#207
• podman-book#189
• kubernetes-basics-book#13
• kubernetes-cluster-ops-book#16
• kubernetes-proxmox-to-cloud-book#20
• proxmox_book#2

Build hygiene

• github-guide-for-beginners-book#225
• github-workflow-book#235
• ai-era-engineers-mind-book#148
• ai-era-engineers-mind-book#149
• LogicalThinking-AI-Era-Guide#159
• LogicalThinking-AI-Era-Guide#170
• negotiation-for-engineers-book#113

この一覧は固定された真実ではない。Codexは実行開始時と各Phase開始時にlive GitHub状態を取得し、追加・close・supersededを反映する。

---

2. 実行原則

• 稼働中のCodex CLIセッションを継続使用し、新しいCodexプロセスを起動しない
• gh auth status、workspace、全cloneのremote／branch／HEAD／dirty statusを最初に確認する
• workspace外の既存checkout、dirty worktree、non-main checkoutを変更しない
• 必要なリポジトリはworkspace配下へgh repo cloneする
• 同名directoryがある場合はremoteとclean statusを確認し、安全に再利用できなければ一意な別名へcloneする
• 各repoのAGENTS.md、CONTRIBUTING*、README*、workflow、build／QA手順を編集前に読む
• live GitHub状態を正とし、既に完了したIssue／PRを重複作成しない
• 原則として1 source Issue = 1 PR
• 同一repository内は直列化する
• repository間の並列処理は最大3冊まで
• fixed latest mainからbranchを作る
• force push、履歴改変、既存branch破壊を行わない
• セキュリティ、本文、QA、visual、build hygieneを無関係に混在させない
• review本文、inline comment、suggestion、threadを全件確認する
• unresolved review threadを0にする
• local QA、PR CI、merge後main、Pages、公開HTTP／markerまで確認する
• private管理書籍のrepository名、Issue／PR番号、URL、本文、path、artifactをpublic Issueへ露出しない
• API secondary rate limitを避け、取得を集約し指数バックオフを使う
• 各Phaseの開始・完了・blockerを本Issueへコメントする
• 各Phaseの完了後に不要branch、task clone、一時artifact、テスト用Issueをcleanupする

---

3. Phase 0 — 現在状態の再取得と実行計画

• 本Issue、[Roadmap][Post-#258] 書籍群の供給網・build契約・自動保守・内容鮮度・Pages運用を段階改善する #265、[Review 2026-08-15][Pages] legacy managed runtimeとcustom deployment移行判断を全公開書籍で再評価する #271、#275をコメント込みで取得する
• docs/_data/catalog.jsonから実行時点のstatus=publishedリポジトリを抽出する
• published repositoryごとのdefault branch SHA、Open Issue、Open PR、最新CI、Pages API、公開HTTPを取得する
• public／private境界を確認する
• 上記「監査開始時点」とlive状態の差分を表にする
• completed／superseded／追加債務を分類する
• Phase別の予定repository、Issue、PR分割を本Issueへコメントする

編集・mergeは初期監査コメントの投稿後に開始する。

---

4. Phase 1 — P0 Open PR・依存脆弱性を解消する

1A. Ethereum Hardhat migration

対象:

• ethereum-learning-bootcamp#135
• PR ethereum-learning-bootcamp#136

実行:

• PR本文、全review、inline、thread、CIを確認する
• Node.js 22.13.0／24 matrix、Hardhat tests、coverage、gas、deploy safety、install-script policyを確認する
• root／dappのhigh／critical 0を確認する
• Sepolia／OP Sepoliaのみ、mainnet拒否、secret境界を維持する
• mergeableで問題がなければmergeする
• main CIと公開Pagesを確認する
• #135へ証跡を記録してcloseする

PR #136へ#133、#134、#131、#132を混在させない。

1B. evidence-based-engineering-book dependency

対象:

• evidence-based-engineering-book#33

• audit JSONでdependency pathを確定する

• npm audit fix --forceを無根拠に使用しない

• moderate／highを0にする最小更新を行う

• lint、link、build、Book QA、Pagesを確認する

• source Issueへ証跡を記録してcloseする

1C. Bioinformatics Dependabot PR

順序:

1. BioinformaticsGuide-book#545
2. BioinformaticsGuide-book#544

PR #545:

• Biopython 1.81→1.87のAPI／behavior差分を確認する
• Entrez parser security fixの影響を確認する
• PairwiseAligner既定値変更の影響を確認する
• semantic freshness registryとE2Eラボを実行する
• Python version matrix、requirements／lock、licenseを確認する

PR #544:

• checkout v7のfork PR、pull_request_target、workflow_run trust boundaryを確認する
• setup-node更新のcache／runtime契約を確認する
• least privilegeとfull SHA pin方針を維持する

各PRでreview、CI、main、Pagesを確認し、merge後Open PR 0を目標にする。

1D. Ethereum active Actions SHA pin（live監査で追加）

対象:

• ethereum-learning-bootcamp#137

#135 / PR #136のmerge後に同一repository内を直列処理する。

• active workflowの外部Actionを監査済み40文字commit SHAへ固定する
• mutable ref再導入をnegative fixtureでfail-closed検出する
• workflow permissions、fork PR、secret境界を維持する
• #135と別branch・別PRでreview、CI、main、Pages、HTTPを確認する
• source Issueへ証跡を記録してcloseする

Phase 1完了条件

• Ethereum PR #136がmergedまたは根拠付きで再設計されている
• Ethereum root／dapp high／critical 0
• evidence-based-engineering-book#33が完了
• Bioinformatics PR #544／#545が完了または根拠付きでclosed
• Open security／dependency PR 0

---

5. Phase 2 — Scheduled Maintenanceを実際の修正へ接続する

対象:

• practical-auth-book#173
• ai-testing-strategy-book#198

practical-auth-book

開始時点の検出:

• install/build infrastructure: failure

• outdated: false

• production audit: false

• external link: false

• workflow run、artifact、Step Summaryを取得する

• install／buildの具体的failureを再現する

• infrastructure failureをsource Issueへ分離する

• 最小PRで修正する

• maintenance workflowを再実行する

• 復旧時に#173が証跡付きで自動close／更新されることを確認する

ai-testing-strategy-book

開始時点の検出:

• install/build infrastructure: success

• outdated: true

• production audit: false

• external link: true

• outdated packageを個別に分類する

• breaking change、security、runtime影響を確認する

• external linkをtransient、redirect、恒久404／410へ分類する

• 必要なsource Issue／PRを分ける

• merge後にmaintenanceを再実行する

• 同一fingerprintの重複Issue抑止と復旧closeを確認する

Phase 2完了条件

• 2件の自動maintenance Issueが具体的source修正へ接続されている
• 検出あり／なし／重複／復旧の契約が実運用で確認されている
• 未解決の自動alertはowner、再現手順、期限を持つ

---

6. Phase 3 — #275を完了監査し、カタログを同期する

#275 final audit

• #275の全checklistを再取得する
• Ethereum除外が維持されていることを確認する
• public source Issueのcompleted／not planned／supersededを再集計する
• private対象は件数と完了状態だけを公開側へ記録する
• #275対象repositoryのOpen PR 0を確認する
• unresolved review 0、main CI、Pages、HTTP証跡を確認する
• 現在残るIssueが#275対象か継続債務かを分類する
• 完了条件を満たせば#275をCompletedとしてcloseする

catalog post-remediation sync

it-engineer-knowledge-architectureで:

• 変更対象書籍のlastReviewedAtを実態と合わせる
• reviewIssueを正しい横断レビュー／remediation Issueへ合わせる
• sourceRefsへ最新source Issue、PR、merge SHAを追加する
• reader summary、prerequisites、recommendedAfterへの影響を確認する
• updatedAtを実際の同期日に更新する
• catalog derived filesとdebt reportを再生成する
• /books/、/paths/、/en/の集合・件数・表示を確認する
• npm run verify、production smoke、Pages driftを確認する

Phase 3完了条件

• #275が完了または残件が明確な子Issueへ分離されている
• catalogのレビュー証跡がPost-remediation状態と一致する
• portal Open PR 0

---

7. Phase 4 — QA Coverage Sprint

対象:

• supabase-architecture-patterns-book#150
• kubernetes-proxmox-to-cloud-book#42
• IT-engineer-communication-book#143
• IT-engineer-communication-book#141

Supabase recursive link QA

• shell glob依存をやめ、決定的な再帰列挙へ変更する
• expected file countをassertする
• nested fixtureを追加する
• existing fragment debtを新規回帰と分ける
• 全source Markdownを検査対象にする

Kubernetes Proxmox links

• 導入3ページの付録相対リンク7件を修正する
• route／base path／fragment assertionを追加する
• screenshot作業#20とは別PRにする

IT engineer communication QA

• UX flagを1件だけ変えるnegative fixture
• root／docs consistency positive test
• built _site/book-config.jsonのProfile／modules assertion
• external URL抽出、timeout、retry、redirect、404／410分類
• scheduled／manualの非ブロッキング監視
• Pages間の主要「次に読む」リンクを監視する

Phase 4完了条件

• 検査対象漏れがfixtureで検出可能
• source／built artifact／Pagesの三層で回帰を検出
• 外部ネットワーク一時障害がPR必須checkをflakyにしない

---

8. Phase 5 — Ethereum残り4件をIssue単位で処理する

順序:

1. ethereum-learning-bootcamp#133
2. ethereum-learning-bootcamp#134
3. ethereum-learning-bootcamp#131
4. ethereum-learning-bootcamp#132

#133 Foundry invariant

• 実在するtest fileを追加する
• failureし得る意味のあるinvariantへ置換する
• handler／target contract／bounded inputを定義する
• negative testで偽のsecurity assuranceを防ぐ

#134 ERC-2981

• zero receiver拒否
• 10000 bps超拒否
• boundary tests
• EIP-2981／OpenZeppelin現行契約と整合

#131 The Graph

• 現行CLI／Subgraph Studio構文へ更新
• product、slug、directory、networkの役割を分離
• clean environmentでscaffold可能か確認

#132 IPFS onboarding

• 新規利用不能なInfura routeを現行導線へ更新
• Pinata等の現行手段、credential、upload、gatewayを確認
• 特定vendor依存と標準IPFS概念を分離する

Phase 5完了条件

• 4 source Issueが別PRで完了
• contract test、docs、CI、Pagesが一致
• secret、testnet、mainnet safetyを維持

---

9. Phase 6 — 構成修正後にVisual Evidence Sprintを行う

先行修正

1. podman-book#207
2. kubernetes-proxmox-to-cloud-book#42（Phase 4で完了済みであること）

Podman:

• 第5・8・9章の見出し、本文主題、navigation、演習、学習パスを同期する
• screenshot pathへ影響する章構成を先に確定する

Visual Evidence対象

• podman-book#189
• kubernetes-basics-book#13
• kubernetes-cluster-ops-book#16
• kubernetes-proxmox-to-cloud-book#20
• proxmox_book#2

共通仕様:

• 対象OS／製品／versionをcaptionへ記録する
• IP、hostname、username、email、token、secret、organization情報をマスクする
• alt textに画面名だけでなく判断ポイントを含める
• captionに見るべき指標／操作意図を含める
• P0画像だけを先に処理する
• 1書籍1PR、必要なら章単位に分割する
• image path、参照、broken asset、duplicate、サイズを検査する
• Playwright／visual smokeでmobile／desktop表示を確認する

Phase 6完了条件

• 構成変更後のpathへ画像を配置
• 機微情報検査を通過
• alt／caption／versionが全画像にある
• build、Pages、主要画像URLが正常

---

10. Phase 7 — Build Hygieneをroot cause別に処理する

対象:

• github-guide-for-beginners-book#225
• github-workflow-book#235
• ai-era-engineers-mind-book#148
• ai-era-engineers-mind-book#149
• LogicalThinking-AI-Era-Guide#159
• LogicalThinking-AI-Era-Guide#170
• negotiation-for-engineers-book#113

分類:

1. upstream更新で解消可能
2. unused tool／dependency削除で解消可能
3. shared template／formatterで解消可能
4. managed Jekyll／GitHub Pages依存で直接解消不能

原則:

• warning文字列だけを消すoverride／log filterを追加しない
• npm explain／npm ls／Bundler dependency chainを記録する
• audit悪化を許容しない
• representative pilot後に同一root causeへ横展開する
• 上流待ちはupstream URL、影響、owner、next review date、early triggerを持つ
• shared.lastSyncは実際の用途、正本性、更新ownerを定義し、不要なら削除する

Phase 7完了条件

• 対象Issueが解消または期限付き上流待ちとして整理されている
• build／test／Book QA／Pages成功
• warning隠蔽がない

---

11. Phase 8 — Portfolio Healthビューを実装する

it-engineer-knowledge-architectureに、書籍群のメンテナー向け状態ビューを追加する。

必要なら本Issueの子Issueをポータルへ作成し、別PRで実装する。

収集項目

• repository
• visibility／publication scope
• default branch SHA
• Open Issue／PR数
• 最新Book QA
• 最新Pages deployment
• Pages build type／status
• 公開HTTP
• lastReviewedAt
• scheduled maintenance alert
• security／freshness／QA／visual／build debt
• 次の推奨作業

成果物

• portfolio-health.json
• portfolio-health.htmlまたは同等のPages view
• Workflow summary／artifact

設計要件

• GitHub API由来の動的値をcatalog正本へ保存しない
• 定期生成物をmainへcommitしない
• Pages build artifactまたはWorkflow artifactへ含める
• status変化時だけ通知する
• 重複alert Issueを作らない
• private管理書籍は公開可能な集計だけ表示する
• healthy / attention / blocked / scheduled等の状態を根拠付きで算出する
• rate limit、retry、cache、partial failureを扱う
• fixtureによる正常／異常／private redaction test
• manual refreshとscheduleを提供する

Phase 8完了条件

• published書籍をcatalog母数として自動集計
• Open Issue／PR、CI、Pages、HTTP、review dateを一画面で確認可能
• private情報漏えいなし
• bot commitなし
• false positive／duplicate alertなし

---

12. Phase 9 — 2026-08-15に#271を実行する

原則として2026-08-15（Asia/Tokyo）以降に実行する。

前倒し条件:

• GitHub managed Pages runtime更新

• runtime起因のdeployment failure

• Pages APIがbuilt以外

• 公開URLがHTTP 200以外

• managed warningがfailureへ昇格

• GitHubが明示的な移行期限を発表

• 実行時点のcatalog published集合を母数にする

• legacy／workflow件数を再集計する

• managed warningとrepository管理warningを分離する

• 公開HTTP、deployment、failure rate、durationを確認する

• custom deploymentの費用、identity、smoke、drift、rollbackを比較する

• pilotが必要なら最大2冊だけ実施する

• 全冊一括移行を行わない

• 書籍ごとにmanaged継続／更新待ち／pilot候補／即時移行／設定修復を分類する

• #271へ証跡を記録してcloseする

• #265の全完了条件を確認し、満たせば#265をcloseする

---

13. 各PRの標準完了条件

• source Issue本文と対象外を維持
• latest mainからbranch作成
• 最小差分
• local QA成功
• negative fixtureまたは反証可能な検査
• git diff --check
• PR本文に根拠、before／after、test、rollbackを記載
• review本文／inline／suggestion全件確認
• unresolved thread 0
• PR CI green
• merge
• main CI green
• Pages／公開HTTP／marker確認
• source Issueへ証跡コメント
• branch cleanup

---

14. 本Issueの完了条件

• Phase 0〜8が完了
• 2026-08-15以降または前倒し条件でPhase 9が完了
• EthereumのP0／P1残件が完了
• maintenance alert 2件が復旧またはowner付きで管理
• Bioinformatics Dependabot PRが処理済み
• #275が完了監査済み
• catalogがPost-remediation状態と一致
• QA coverageの検出漏れが解消
• structure修正後にVisual Evidenceが追加
• build warningがroot cause別に整理
• Portfolio Healthビューが稼働
• #271完了
• #265完了
• ポータルと対象書籍のOpen PR 0
• unresolved review thread 0
• workspace cleanup証跡

---

15. 稼働中Codex CLIへの実行指示

このIssue番号を取得した後、稼働中のCodex CLIセッションへ次を渡す。

GitHub Issue itdojp/it-engineer-knowledge-architecture#<THIS_ISSUE> をgh CLIでコメント込みで全文取得してください。関連Issue #265、#271、#275も取得してください。本Issueを正本Runbookとして、現在のCodex CLIセッション内でPhase 0から依存順に処理してください。

新しいCodexプロセスは起動しないでください。必要なリポジトリは現在のworkspace配下へgh repo cloneしてください。workspace外の既存checkout、dirty worktree、non-main checkoutは変更しないでください。

最初にlive GitHub状態を再監査し、Issue記載の開始時点との差分、実行計画、PR分割を本Issueへコメントしてください。その後、1 source Issue = 1 PR、同一repo直列、最大3repo並列で進めてください。レビュー本文・inline・suggestion・threadを全件確認し、unresolved 0、CI、main、Pages、公開HTTPまで確認してください。

Phase完了ごとに証跡を本Issueへ記録し、完了したchecklistを更新してください。2026-08-15前で前倒し条件がないPhase 9は実行せず、scheduledとして残してください。全完了条件を満たした場合だけ本Issueをcloseしてください。

[ootakazuhiko]

稼働中Codex CLIへ渡す指示

以下を現在のCodex CLIセッションへそのまま渡してください。

GitHub Issue itdojp/it-engineer-knowledge-architecture#276 をgh CLIでコメント込みで全文取得してください。関連Issue #265、#271、#275も取得してください。Issue #276を正本Runbookとして、現在のCodex CLIセッション内でPhase 0から依存順に処理してください。

新しいCodexプロセスは起動しないでください。最初にpwd、gh auth status、workspace内の全cloneのremote・branch・HEAD・dirty statusを確認してください。必要なリポジトリは現在のworkspace配下へgh repo cloneしてください。workspace外の既存checkout、dirty worktree、non-main checkoutは変更しないでください。

最初にlive GitHub状態を再監査し、Issue記載の開始時点との差分、実行計画、PR分割をIssue #276へコメントしてください。その後、原則1 source Issue = 1 PR、同一repo直列、最大3repo並列で進めてください。既に完了したIssueやPRを重複作成せず、live GitHub状態を正としてください。

各PRではreview本文、inline comment、suggestion、threadを全件確認し、unresolved 0、local QA、PR CI、merge後main、Pages、公開HTTP／markerまで確認してください。private管理書籍の非公開情報をpublic Issue、PR、artifact、ログへ出力しないでください。

Phase完了ごとに証跡をIssue #276へ記録し、完了したchecklistを更新してください。Phase 9は2026-08-15（Asia/Tokyo）前で前倒し条件がない場合は実行せずscheduledとして残してください。blockerが発生した場合は、可能な範囲まで完成させ、具体的な原因、影響、owner、再開条件をIssue #276へ記録してください。

全完了条件を満たした場合だけIssue #276をcloseしてください。

[ootakazuhiko]

Phase 0 — live再監査と実行計画（2026-07-22 JST）

Issue #276、関連 #265 / #271 / #275をコメント込みで取得し、docs/_data/catalog.jsonを唯一の母数としてlive GitHub状態を再監査しました。編集・PR作成はまだ開始していません。

workspace / 安全境界

• workspace: /home/devuser/work/CodeX/booksB
• 専用run: runs/iteka-276-20260722
• portal clone: runs/iteka-276-20260722/repos/it-engineer-knowledge-architecture
• cloneはclean main、origin一致、HEAD d6bf69cda7c478b770a84b7264754a71e9279cf4
• workspace内147 checkoutのremote / branch / HEAD / dirtyを確認。既存dirty checkout、non-main checkout、workspace外checkoutは再利用・変更しない。
• 新しいCodexプロセスは起動していない。

catalog母数と横断状態

項目	live状態
published	42（main lineup 41 + related independent 1）
public / private管理	40 / 2
public default-branch check rollup	SUCCESS 39 / null 1
public Pages build type	legacy 33 / workflow 7
public Pages API status	built 38 / null 1 / errored 1
public root HTTP	200: 40/40
private管理集計	default check SUCCESS 2/2、root HTTP 200: 2/2（識別情報は非掲載）
portal	drift success、Pages built/workflow、HTTP 200、Open PR 0
public書籍 Open Issue / PR	25 / 1
private管理 Open Issue / PR	0 / 2（集計のみ）

latest actionの例外は、practical-auth-bookのScheduled Maintenance failure（Phase 2対象）です。公開runtimeは全42冊でHTTP 200ですが、Pages APIにbuilt以外が3冊（public 2、private管理 1）あります。これは#271の前倒し条件に該当するため、Phase 9を単なるscheduledとはせず、依存順を維持してPhase 8完了後に再確認し、#271 Runbookを実行対象とします。API statusだけで障害と断定せず、exact deployment、Actions、HTTP、markerを併用して分類します。

「監査開始時点」とlive状態の差分

対象	Issue記載	live	分類
portal Open Issue	#265 / #271 / #275	#265 / #271 / #275 / #276	本実行Issue追加のみ
portal Open PR	0	0	変更なし
Ethereum migration PR	1件	1件open	Phase 1継続。重複PRなし
private管理 dependency PR	2件	2件open	Phase 1で直列監査。公開側は集計のみ
Runbook記載public source Issue	25件open	25件open	completed / superseded / 新規追加なし
#275	Open、Visual Evidence 1件残	checklist 164/167、source 118/119完了、同じ1件がopen	Phase 3/6で再判定
#271	Open、通常日2026-08-15	Open、Pages API非builtを観測	前倒し条件あり。Phase 8後に実行

開始時点の3 Open PRと25 public source Issueはlive状態でも同一です。private管理側の詳細はpublic Issueへ出力しません。

依存順・PR分割

1. Phase 1
   • Ethereum Docs: foreground composable book in English catalog #135: 既存PR #136を再監査・merge（他4 Issueは混在させない）
   • evidence-based-engineering-book 【移管】theoretical-computer-science-textbook: 内部リンク方針の統一（.md/.html/スラッシュの混在解消） #33: 1 Issue = 1 PR
   • private管理dependency PR 2件: 同一repo内をRunbook順に直列処理
   • repository間は最大3冊並列、ただしmerge/rebase/reviewはrepo単位で直列化
2. Phase 2
   • practical-auth [Quality Sprint] 2026-07-01 #173、ai-testing #198を別トラックで調査
   • infrastructure / package / external-linkのroot causeごとにsource IssueとPRを分離
3. Phase 3
   • #275の118/119証跡を再監査し、残件をPhase 6へ接続
   • catalog同期はportal子Issueを作成し、1 PRに限定（本文修正と混在させない）
4. Phase 4
   • [Quality Sprint] 2026-04-15 #150 / Books: 非存在コンテンツURLの集約リスト（要追補/要リンク修正） #42 / Add publishing quickstart page #143 / #141をそれぞれ1 PR、同一repoのみ直列
5. Phase 5
   • Ethereum [publishing] Clarify the relationship between categorical-software-design-book and composable-software-design-book across all public surfaces #133 → Docs: clarify categorical and composable book relationship #134 → 英語版 catalog ページ整備：/en/ 新設、日本語メイン維持、全書籍への英語説明追加 #131 → #132を各1 PRで直列
6. Phase 6
   • Podman #207を先行1 PR。その後Visual Evidence 5書籍を原則1書籍1 PR
   • 実機・真正画面を取得できない対象は合成で代替せず、owner / 再開条件 / 期限を記録
7. Phase 7
   • 7 source Issueを各PRに分離。root cause共通化は代表pilot後のみ横展開
8. Phase 8
   • portal子Issueを作成し、Portfolio Healthを専用PRで実装
9. Phase 9
   • 現時点で前倒し条件を観測。Phase 8後に#271を全catalog母数で実行し、pilotは必要時最大2冊
10. 各Phase完了時に本IssueへPR / merge SHA / review completeness / CI / main / Pages / HTTP / cleanup証跡を追記し、該当checklistを更新する。

共通merge gate

全PRでlatest main起点、最小差分、local QA、negative fixture、git diff --check、review本文 / inline / suggestion / thread全件確認、unresolved 0、PR CI、exact merge SHAのmain / Pages / HTTP・markerを必須とします。private管理情報はsource側だけへ記録し、本public roadmapでは件数と状態だけを扱います。

[ootakazuhiko]

Phase 1開始（2026-07-22 JST）

Phase 0計画後、3 repositoryを専用run配下へclean main cloneし、source Issue、既存PR、権限、CIを再取得しました。同一repoは直列、repo間は最大3冊で進めます。

live入口

• Ethereum Docs: foreground composable book in English catalog #135 / PR [Quality Sprint] 2026-03-15 #136: Open。head fba8211a7f009d2fe948c18be55323d50d245942、MERGEABLE / BLOCKED、review 5件、最新headの6 checksはsuccess。source Issueにはreview completeness unresolved 0とlocal QA証跡が記録済み。
• 現認証は対象repoでmaintain=true / admin=false。通常mergeは既にbranch policyで拒否されているため、実装再作業ではなくexact-head再監査後のadmin merge権限が再開条件。ownerはrepository administrator、影響はPhase 1A完了とPhase 5開始順序。Phase 1B / private dependency trackは独立して進める。
• evidence-based-engineering-book 【移管】theoretical-computer-science-textbook: 内部リンク方針の統一（.md/.html/スラッシュの混在解消） #33: Open。依存pathと現在のauditをclean cloneで再現し、1 Issue = 1 PRで最小更新する。
• private管理dependency PR: 2件ともOpen。同一repo内をRunbook順に処理し、公開roadmapには件数・完了状態だけを記録する。

各trackでrepo固有のAGENTS.md、contribution/build/QA契約を先に読み、review本文・inline・suggestion・thread全件、unresolved 0、CI、main、Pages、HTTP/markerをmerge gateにします。

[ootakazuhiko]

Phase 1A再監査: Ethereum migration PRはexact head fba8211a7f009d2fe948c18be55323d50d245942でlocal全QA、root/dapp high・critical 0、required checks 6/6、Codex exact-head review、独立security review、review completeness unresolved/mismatch/missing 0を確認しました。通常squash merge再試行はbase branch policyで拒否され、現資格情報はmaintain/non-adminです。原因=単独運用で通常merge不能なpolicy、影響=Phase 1A完了とPhase 5開始、owner=repository administrator、再開条件=同headへのadmin squash merge権限。source側へ詳細証跡を記録済みです。Phase 1B/Cは独立して継続します。

[ootakazuhiko]

Phase 1Aの独立reviewで、Ethereumのactive workflowにmutable major tag参照が残る追加supply-chain債務を確認しました。既存Issue検索で重複0のため、source側に別Issueとして登録しました（Hardhat PRへ混在させず、#135完了後に同repo直列処理）。公開roadmap上はsource Issue URLを証跡として扱います: itdojp/ethereum-learning-bootcamp#137

[ootakazuhiko]

Phase 1B完了: evidence-based-engineering-book#33をPR #39で完了しました。merge 5b8804488753d12de5368830c96ecc7fdc7e8e5b。Node 22.22.2でclean install、deprecated warning 0、audit 0、lint/link/build/Book QA/diff check成功。Copilot/Codex 4 actionable threadを全修正・返信・resolveし、completeness reviews 6 / comments 8 / threads 4 / unresolved・mismatch・missing 0。exact main CI 29897437408、Book QA 29897437342、Pages 29897436814、deployment 5550959286 success、公開root HTTP 200とmarker確認。source IssueはCompleted、Open PR 0、task branch/artifact cleanup済み。証跡: itdojp/evidence-based-engineering-book#33 (comment)

[ootakazuhiko]

Phase 1C完了（private管理集計のみ）: Runbook指定順の2 PRと、直後に自動生成された追加Actions更新1 PRの計3件を同一repo直列で処理しました。3/3 merged、各PR local QA・review本文/inline/thread・CI・completeness unresolved/mismatch/missing 0。final mainの6 workflows、Pages deployment、公開3 endpoint HTTP 200/markerを確認し、Open PR 0、task branch/artifact cleanup済みです。private管理のrepository名、PR番号、URL、内部path・内容は本public roadmapへ追加掲載していません。

[ootakazuhiko]

PR #136 GitHubルール診断（read-only、2026-07-22 JST）

指定されたghコマンドと追加のread-only API照会を実行しました。PR branch、base branch、repository rules/protectionには変更を加えていません。

結論

直接観測できるmerge blockerは、classic branch protectionが要求する旧check context名と、PR #136のmatrix化後の実check名の不一致です。

branch protectionが要求しているcontext:

• qa — present / success
• Docs forbidden check — present / success
• test — missing
• dapp-build — missing

PR exact headで実際に成功しているcheck:

• qa
• Docs forbidden check
• test (22.13.0)
• test (24)
• dapp-build (22.13.0)
• dapp-build (24)

gh pr checks --requiredにもqaとDocs forbidden checkだけが表示され、test / dapp-buildはrequired contextとして未充足です。matrix jobの成功は、旧base context名を自動的には満たしていません。

指定12項目

1. headRefOid: fba8211a7f009d2fe948c18be55323d50d245942。EXPECTEDと一致。
2. mergeStateStatus: BLOCKED（mergeable=MERGEABLE、draftではない）。
3. reviewDecision: 空値 / null。
4. APPROVED review: なし。全5 reviewはCOMMENTED。review requestも0。
5. required status checks不足: あり。testとdapp-buildの2 contextがmissing。6 matrix checks自体は全success。
6. merge queue必須: 適用中rulesetとしてのmerge_queueは検出されていない。rules/branches/main=[]、parentを含むrepository rulesetsも0件。現時点の可視情報では必須ではない。
7. required signed commits: 現資格ではclassic protection詳細APIが404となり、設定値を直接確認できない。exact headはGitHub API上unsigned。ruleset由来の署名必須ruleは0件だが、classic protection側の有無は断定しない。
8. required deployment: exact headにdeploymentは0件。ruleset由来のrequired deployment ruleは0件。ただしclassic protection詳細APIが404のため、classic設定の有無は直接確認できない。
9. restrict updates / restrict pushes: ruleset由来の該当ruleは0件。classic protectionのrestrictions endpointは現資格で404のため、classic設定値は確認不能。
10. 適用中ruleset source: repository/inherited rulesetは0件。mainはprotected=trueで、可視のrequired checksはclassic branch protectionから来ているため、確認できたsourceはrepository-level classic branch protection。Organization rulesets直接一覧は現tokenにadmin:org scopeがなく取得不能だが、parent-inclusive repository endpointとbranch applicable-rules endpointはいずれも0件。
11. admin / repository role bypass: current actorはMAINTAINでbypass不可。required checksのenforcement_levelはeveryone。admin bypass allowance自体はclassic protection詳細APIが404のため断定不能であり、gh pr mergeの--admin案内だけを「許可されている証拠」とは扱わない。
12. 必要なmerge経路:
    • 現状の正常merge: 不可。旧required context 2件が未充足。
    • 承認追加: APPROVEDはないが、reviewDecisionはnullであり、承認追加だけではmissing status contextを解消しない。
    • merge queue: 必須である証拠なし。missing contextを解消しない。
    • admin bypass: current actorでは不可。admin bypassが実際に許可されていれば代替になり得るが、現資格からは許可設定を確認できない。

推奨される修復方針（今回は未実施）

通常mergeを回復する正攻法は、repository administratorがbranch protectionのrequired status checksを現在のmatrix check名へ同期するか、workflow側に旧required context名test / dapp-buildを満たす集約jobを別変更として設けることです。どちらを採る場合も、PR #136の実装変更と混在させず、設定または別PRとして監査します。

この診断ではruleset変更、branch protection変更、push、rebase、base更新、admin merge、Issue closeを実施していません。

[ootakazuhiko]

Phase 1A完了 — Ethereum #135 / PR #136（2026-07-22 JST）

classic branch protectionのrequired context test / dapp-buildとNode matrixの表示名不一致は、branch protection変更やadmin bypassではなく、PR #136内のstable aggregate jobで解消しました。

• 診断時head: fba8211a7f009d2fe948c18be55323d50d245942
• stable gate commit / PR最終head: 90facaf572aefefd7a3361ddbc384f3814101a7b
• aggregate jobはmatrixがfailure / cancelled / skippedの場合に明示的にfailure。外部Action、checkout、installなし
• exact headで8 checks（qa、Docs forbidden check、Node 22.13.0/24のtest・dapp-build matrix、stable test、stable dapp-build）が全success
• review completeness: reviews 5 / comments 8 / threads 4 / unresolved・mismatch・missing 0。Codex exact-head reviewと独立read-only reviewで重大指摘なし
• mergeStateStatus=CLEAN後、admin bypassを使わず通常squash merge
• PR: fix: Hardhat 3へ移行しhigh脆弱性を解消 ethereum-learning-bootcamp#136
• merge SHA: 61c316e284df338d717b5a0f7c65e317aea3857b
• exact mainのtest、Book QA、Docs Forbidden、Nav + Pages Link Check、Pagesの5 workflowは全success
• Pages deployment 5552510159: success / exact merge SHA一致
• 公開rootおよびbuild-infoを含む4 URL: HTTP 200
• marker: revision 61c316e284df338d717b5a0f7c65e317aea3857b / version 2026.07
• exact mainローカル: npm run check:all、16 tests、coverage 86.07%、gas、dapp build成功。root/dapp high・critical 0
• source Issue Docs: foreground composable book in English catalog #135: 証跡記録、checklist更新、Completed close済み
• branch protection / ruleset変更、admin権限によるbypass、force pushは未使用

Phase 1Dのethereum-learning-bootcamp#137は、#135と混在させず、次に別branch・別PRで直列処理します。

[ootakazuhiko]

Phase 1完了 — P0 Open PR・依存脆弱性（2026-07-22 JST）

Phase 1A〜1Dを依存順に完了し、対象repositoryのOpen PR 0を再確認しました。

1A / 1D Ethereum

• Docs: foreground composable book in English catalog #135 / PR [Quality Sprint] 2026-03-15 #136: Hardhat 3 migrationとhigh脆弱性解消
  • normal squash merge 61c316e284df338d717b5a0f7c65e317aea3857b
  • stable required contextをaggregate jobで復元し、branch protection変更・admin bypassなし
  • source #135はCompleted
• [ops] 管理下書籍repoの GitHub Actions Node 20 廃止予告に横断対応する #137 / PR docs: add ai-agent-engineering-book to lineup #138: active Actions SHA pinとfail-closed gate
  • before: active workflow 5 / uses: 18 / mutable 8
  • after: external Action 18/18 full commit SHA
  • YAML構造解析、flow/quoted negative test、direct Docker sha256 digest、required Node 22.13.0/24 matrixへのgate接続
  • Codex 4件 / Copilot 1件を実装修正、返信、resolve
  • completeness: reviews 8 / comments 10 / threads 5 / unresolved・mismatch・missing 0
  • PR docs: add ai-agent-engineering-book to lineup #138: ci: pin active GitHub Actions to audited SHAs ethereum-learning-bootcamp#138
  • normal squash merge 5c7e3b065dbb43af01040366fcbf494f94610b70
  • exact mainのtest / Book QA / Docs Forbidden / Nav + Pages / Pagesは全success
  • Pages deployment 5552909542 success、公開4 URL HTTP 200、marker revision exact一致
  • source #137はCompleted
• Ethereum Open PR: 0
• exact mainローカル: 16 tests、coverage 86.07%、gas、dapp build、root/dapp high・critical 0

1B / 1C再監査

• evidence-based-engineering-book 【移管】theoretical-computer-science-textbook: 内部リンク方針の統一（.md/.html/スラッシュの混在解消） #33: Completed、PR docs(dashboard): add recently closed unification list #39 merged 5b8804488753d12de5368830c96ecc7fdc7e8e5b、Open PR 0
• Bioinformatics PR #545: merged c3acb39106f4cb35bfb3b80a1754437afbf016dc
• Bioinformatics PR #544: merged 753e0ba99ce6de74f3386f7ae1f87d2c6f5fd8e1
• BioinformaticsGuide-book Open PR: 0
• private管理track: 前回記録どおり同一repo直列3/3 merged、Open PR 0（repository識別情報は公開roadmapへ掲載しない）

Phase 1終了状態

• public Phase 1対象3 repository: Open PR 0
• private管理対象: Open PR 0（集計のみ）
• source Issue / PRの重複作成なし
• unresolved review thread 0
• Ethereum task branch、依存install、build / coverage / Hardhat生成物をcleanup
• dedicated checkoutはclean main、HEAD / origin/mainとも5c7e3b065dbb43af01040366fcbf494f94610b70

Phase 1完了条件をすべて満たしたためchecklistを更新しました。次はRunbookどおりPhase 2（practical-auth-book#173、ai-testing-strategy-book#198）へ進みます。

[ootakazuhiko]

Phase 2 live診断・実行計画（2026-07-22 JST）

自動Issue、scheduled run、job/step、artifact API、clone上のworkflow契約を取得し、clean mainで再現しました。両repositoryともOpen PR 0です。対象runのartifactは0件で、Step Summaryへ出した詳細はIssue本文のboolean以外に永続化されていません。

practical-auth-book #173

run: https://github.com/itdojp/practical-auth-book/actions/runs/29733873745

• GitHub runnerのInstall dependencies and build canonical siteはnpm ci成功後、bundle exec jekyll buildでbundle: not found（exit 127）。後続のcontract/outdated/audit/link stepはすべてskipped。
• bundleをPATHから除外したclean再現でもexit 127。ローカルに既存Ruby/Bundlerがある環境では成功するため、runner toolchain契約の欠落と確定。
• Issue本文のoutdated/audit/link=falseは「検出なし」ではなく、skipped outputのdefault値。
• buildから独立して再検査した結果:
  • outdated: fs-extra 11.3.0 → 11.3.6、markdownlint-cli 0.48.0 → 0.49.1（後者はrange外）
  • production audit: high 1 / critical 0。brace-expansion 3.0.0–5.0.6、GHSA-3jxr-9vmj-r5cp、fix available
  • canonical metadata/link validation: success
• 現workflowはfinding/infra時のopen/updateだけで、clean recovery時のcomment/closeを実装していない。

ai-testing-strategy-book #198

run: https://github.com/itdojp/ai-testing-strategy-book/actions/runs/29733412806

• install/build成功、contract test成功、production audit 0。
• outdatedは実在: fs-extra 11.3.0 → 11.3.6、markdownlint-cli 0.49.0 → 0.49.1。
• npm run buildの出力先はdocs/だが、workflowは存在しないpublic/へlinkinatorを実行。The provided glob "public" returned 0 resultsのcommand errorをlinks=trueへ誤分類している。
• 公開URLを同一条件で再監査した93リンクは全success。現時点でtransient / redirect / 404 / 410は0件。したがってexternal-link findingではなくinfrastructure false positive。
• practicalと同様、clean recovery時の自動Issue closeがない。

source Issue / PR分割と順序

同一repository内は直列、repository間は最大2冊で進めます。各source Issueは1 PRです。

practical-auth-book

1. maintenance infrastructure / lifecycle PR
   • canonical Jekyll build toolchainをrunnerで明示
   • install/build、outdated、audit、link command infrastructureをfindingと分離
   • exact link checker version、診断log、stable fingerprint、open/update/no-duplicate/recovery-comment/closeを実装
   • merge後manual rerunで同じ#173がoutdated/audit findingへ更新され、新Issueが増えないことを確認
2. production audit PR
   • brace-expansion high 1件をdependency pathに基づく最小lock修正で解消
   • force fixを使わずproduction high/critical 0
   • rerunで#173がoutdatedのみへ更新されることを確認
3. outdated dependency PR
   • fs-extra / markdownlint-cliを互換検証付きで更新
   • rerunでfinding 0、#173にrecovery証跡が付きCompleted closeされることを確認

ai-testing-strategy-book

1. maintenance link / lifecycle PR
   -存在しないpublic/依存を廃止し、公開rootをexact-version link checkerで検査
   • JSON parse可能なcommand resultだけをfindingとし、command errorをinfraへ分離
   • fingerprint duplicate抑止とrecovery closeを実装
   • merge後rerunで同じ#198がoutdated=true / links=falseへ更新され、新Issueが増えないことを確認
2. outdated dependency PR
   • fs-extra / markdownlint-cliを互換検証付きで更新
   • rerunでfinding 0、#198のrecovery closeを確認

共通merge gate

各PRでlocal clean install、repo固有QA、negative fixture、audit、actionlint、diff check、review本文/inline/suggestion/thread全件、unresolved 0、PR CIを確認します。merge後はexact main workflow、Pages deployment、公開HTTP / markerを確認します。workflow_dispatchの各runでIssue件数、fingerprint更新、failure/finding分離、recovery comment/closeを実測します。

これから重複検索結果0を根拠に上記5 source Issueを作成し、workflow infrastructure PRを2 repositoryで先行します。

[ootakazuhiko]

Phase 2順序調整: practicalのmaintenance実装はworkflow-only local commitまで完了しましたが、再監査で既存active npm run check:securityがbrace-expansionとlinkify-itのhigh 2件を検出し、#174 PRのCIを先にgreenにできません。#175をhigh 2件へ更新し、同repo順を #175（security）→ #174（workflow lifecycle）→ #176（outdated）へ変更します。責務は別branch/別PRのまま維持し、#174実装commitは未pushで分離保持しています。ai-testing側 #199→#200は変更ありません。