一時No-Goのあと、正式v1.0.0をGoにしたのは新機能ではなかった

2026-07-17 に一時 No-Go を選んだとき、v1.0.0-rc1 まで来てテストも通り、Connector もそろっていた。それでも正式版と言い切れなかった。2026-07-26 に正式 v1.0.0 を Go にできた理由を振り返ると、足りなかったのは新機能ではない。毎朝の運用条件を、最後まで事実で説明できるかどうかだった。

この間に増えたのは、DNS の有限再試行、Metricool の非対話 refresh、DarkWake を避ける条件、通常 Wake を待って始めるための調整だ。どれも派手な機能ではない。けれど、これらの条件がそろわない限り、運営 OS は「たまに動く仕組み」のままだった。

一時 No-Go で止めたもの

Season 1では、RC検証週 Day 7 の一時 No-Go と、「動くConnectorと、毎日動く仕組みは別だった」という発見を書いた。いずれも正式 v1.0.0 の前で止まった時点の記録である。

当時の正本は v1.0.0-rc1 で、運用検証の目的は明確だった。朝の読取りが終わり、人が Dashboard を開いたとき、昨日との差だけを見ればよい状態にできるか。そのために 2026-07-11 から7日間の Operational Validation Week を置き、新機能追加を止めた。

ここで固定した役割分担も重要だった。ChatGPT は設計とレビュー、Cursor は実装、GitHub は正本、最終判断は人間。役割が分かれていたから、進捗を「何を足したか」ではなく、「何が正式版の条件か」で見続けられた。

直したのは機能ではなく運用条件

一時 No-Go のあとにやりたくなるのは、監視、通知、AIによる説明といった機能追加かもしれない。だが GitHub の CHANGELOG.md、release note、Operational Validation Report に残っている実際の修正は、Version 1.0 に必要な範囲を広げず、朝の無人運用が止まる条件を最小差分で詰めることだった。

• DNS / 一時通信障害の有限再試行
• Metricool OAuth の非対話 refresh
• DarkWake 中は Connector を開始しない条件
• 通常 Wake 後に実行を始めるための待機

問題は「Connector が壊れている」ことではなく、「朝の運用条件を最後まで定義し切れていない」ことだった。だから、直す対象は部品の追加ではなく、条件の明文化と再検証になった。

2026-07-26 の最終無人検証で、ようやくその条件を事実で言えるようになった。DarkWake 中は開始しない。通常 Wake 後に4 Connectorが保存まで進む。GA4 / GSC / Clarity は success、Metricool は既知許容の partial で7/7保存、wrapper は exit code 0、stderr は空、テストは178 Green。この時点で、Go の説明責任が成立した。

同日に正式 v1.0.0 が GitHub Release として公開された。その後の v1.1.0 は、毎朝60秒で判断しやすくするUI改善であり、v1.0.0 をGoにした条件とは別の話として扱われている。

範囲を狭く保つことが、Goを強くする

正式版の条件は、機能の量ではなく、言い切れる条件の量で決まる。テストが多いことも画面がそろっていることも重要だが、それだけでは毎朝の不安は消えない。「なぜ今日は更新されていると言えるのか」を人が説明できるとき、初めて運用は安定する。

だからこの期間は、Human Approval を外さない、DBを変えない、新しいConnectorを足さない、Version 1.0 を次の願望で汚さない、という線を守った。GitHub に Current Status、Lessons Learned、CHANGELOG、release note がそろっていたから、会話の勢いではなく確認済みの事実へ戻れた。

非エンジニアの立場でも、すべての実装詳細を理解する必要はない。Version の境界と Go / No-Go の説明責任を見失わないことはできる。ChatGPT と Cursor の役割を分け、GitHub に記録を残し、人間が最後に線を引く。この運営の形そのものが、v1.0.0 をGoにした条件の一部だった。

持ち帰れること

• 一時 No-Go のあとに必要なのは、機能追加ではなく条件の言い直しであることがある
• Connector の品質と、毎朝の運用条件の品質は別物
• 正式リリースの説明責任は、テスト件数だけでは成立しない
• Version の境界を守ると、修正の対象が狭まり、Go / No-Go の判断が強くなる
• AI、実装、正本、人間の最終判断を分けると、判断の質を安定させやすい

この記事は、CURRENT_CONTEXT.md、Operational Validation Report、CHANGELOG.md、正式Releaseの確認済み事実だけで構成している。未実装の次Version機能や将来計画は含めていない。