一度に全部直さない。1か所ずつGOを出す

未確認の1枚を検証し、成立後に残り3枚へ進む段階実行の図解 ブログを会社化する設計

AIへ頼む変更先に、同じ形のカードが4枚並んでいれば、一度に直せそうに見える。

俺も、トップページの4枚へリンクを付けるとき、最初はまとめて変更しようとした。

だが、未確認だったのはリンク先ではなかった。

WordPressを通ったあとのHTMLがどうなるか。

リンクがカード内に収まり、PCとスマホ、TabとEnterでも使えるか。

そこまで確認できる前に4枚へ広げると、不具合の原因を切り分けにくくなる。

そこで、最初に試す範囲を1枚へ戻した。

全部を1枚ずつ直したかったわけではない。

未知の構造を、次へ進めると判断できるところまで確かめたかった。

4枚のカードを、一度に直そうとしていた

トップページには、「THREE STOPS」と公開後施工を示す4枚のカードがある。

企画確認、本文・レビュー、WordPress下書き・アイキャッチ、公開後施工である。

4枚は同じ一覧の中にあり、同じHTML構造と見た目を使っていた。

そのため、最初の施工planでは4枚を1回で変更する案にした。

同じ構造なら、同じ変更をまとめた方が確認しやすいと思っていた。

ただし、本当に同じだったのは変更前の見た目までだった。

WordPressがHTMLをどう整形し、リンクをどの範囲へ置くかは未確認だった。

同じ形に見えることと、同じ方法で変更できることは別だった。

未確認の構造まで、まとめて承認しようとしていた。

不一致が出たので、beforeへ戻した

編集画面側のHTMLは予定どおりでも、公開ページではWordPressの自動整形によって構造が変わっていた。

カードの直下に置いたリンクが、公開ページでは段落に包まれていた。

予定した構造と違う以上、その上へCSSを足して合わせることはしなかった。

そこで、変更前に保存したbeforeへ戻した。

変更前を残す理由については、前に変更する前にbeforeを残すようにしたとして整理した。

戻したあとに考えたのは、どうすれば4枚を一気に通せるかではない。

何を確認できれば、同じ構造だと判断してよいかだった。

変更範囲を決める前に、確認条件を決め直した。

未確認の構造は、1枚目だけで試すことにした

調査すると、確認したいことは1枚で判断できると分かった。

リンクが公開HTMLでもカードの直接の子として残り、カード内だけを覆うか。

PCとスマホで崩れず、hover、focus、Tab、Enterが機能するか。

そして、ほかの3枚と既存の役割カードを変えずに維持できるか。

この条件は、4枚すべてへ反映しなくても確認できる。

そこで「停止1:企画確認」の1枚だけを検証対象にした。

1枚が通ったら、同じ構造として残りへ進む。

通らなければ、1枚だけをbeforeへ戻して原因を見直す。

次のGOに必要な答えを、最小の変更で得るためだった。

1枚だけでも、リンクはページ全体を覆った

1枚だけの施工でも、不具合は出た。

PCの実画面で確認すると、停止1のカードは約184×205pxだった。

ところが、カード全体を押せるようにしたリンクは、約859×4,565pxまで広がっていた。

原因は、リンクの基準になるはずのカードのCSSが、公開側で有効になっていなかったことだった。

保存されたHTMLの形とリンク先だけを見ていたら、通過させていたかもしれない。

この状態では、hoverやTab、Enter、スマホ表示の確認を続けても意味がない。

リンク範囲が成立していないからである。

そこで追加修正には進まず、再びbeforeへ戻した。

不具合を1枚の範囲で見つけ、ほかの3枚へ広げずに戻せた。

小さくしたのは、失敗の可能性ではなく、失敗を抱える範囲だった。

1枚で確認してから、残り3枚へ進んだ

次の施工では、カード自身がリンク位置の基準になるよう指定方法を変えた。

まず、停止1の1枚だけをもう一度反映した。

PC幅1280pxでは4列を維持し、横スクロールもない。

スマホ幅390pxでは1列になり、文字やカード幅も崩れなかった。

hoverでは背景が変わり、TabとEnterでも操作できた。

リンクとカードの矩形差は、PC・スマホとも約3px以内だった。

ここまで確認して、初めて同じ構造を残りへ使えると判断した。

その後は、停止2、停止3、公開後の3枚をまとめて反映した。

最後に4枚のリンク先、PC・スマホ表示、Tab順、focus、Enterでの移動を確認した。

だから残りまで、1枚ずつ同じ検証を繰り返す必要はなかった。

段階実行で分けたかったのは、作業件数ではなく不確かな部分である。

GOは、次の確認地点まで進める許可だった

実装前に止まるルールについては、前にClaude Codeが勝手に動く。CLAUDE.mdに「2つのルール」を書いたら止まるようになったとして整理した。

そのときは、AIが実装前に止まる仕組みを作った話だった。

最初のGOは、4枚を完成させる許可になっていた。

見直したあとのGOは、停止1の構造と表示を確かめるところまでだった。

修正版の1枚がPC、スマホ、Tab、Enterまで通ったら、残り3枚へ進む。

同じ見た目でも、まだ成立を確認していない構造だけを小さく試す。

成立したあとは、確認済みの範囲としてまとめる。

GOは、AIを信用したという合図ではなかった。

次の確認地点まで進めてよいという許可だった。

俺が小さくしたかったのは作業量ではない。

次のGOまでに抱える、未確認の範囲だった。

コメント