childhood

Childhood

リリース後も、そのリリースを追跡してください。ユーザーに届くものと本番環境で提供されているものを検証し、確認済みのリグレッションがあれば、ユーザーが許可した範囲内で修正してください。マージや公開コマンドの成功は、この作業の始まりにすぎません。

リリースを特定する

• リポジトリ、リリースバージョン、不変のタグコミット、マージコミット、本番デプロイ、および影響を受ける配信面を特定してください。リリースの記録と実際のプロバイダー／レジストリの状態を使い、現在のブランチや今日の最新ビルドから推測しないでください。
• 利用可能な場合は work_state_write を使って、リリース、観測の開始／終了時刻、チェック、調査結果、次のアクションを記録してください。告知と、製品のリグレッションとは無関係なインフラ障害を区別できるようにしてください。
• 既存の許可を引き継いでください。監視だけでは、追加リリース、ロールバック、本番移行、外部への告知は許可されません。まだ必要な許可を求める前に、具体的な修正を準備して検証してください。

リリースされたものを検証する

配信面に応じたチェックを選択してください。相互に独立したチェックは並行して実行できます。

配信面	収集する証拠
ソースと CI	タグが出荷済みのコミットを指していることを確認します。そのコミットと、リリース／変更履歴に関するコミットの CI を調べ、遅れて発生した失敗も確認します。リリース後の新しい課題報告、マージ済み PR のコメント、レビュー、レビューのスレッドをページネーションして調べ、対応が必要な報告を出荷済みコードと照合して検証します。
公開済みパッケージ	レジストリの正確なバージョンと、意図された配布タグを別々に確認します。ダウンロードしたアーティファクトのパッケージハッシュ、エントリーポイント、必須ファイルを検証し、分離したディレクトリからインストール済み CLI の簡単なスモークテストを実行します。出力をフィルタリングする際は、コマンドの実際の終了コードを保持してください。
ホステッドサービス	稼働中の本番エイリアスが、意図されたデプロイ／コミットを提供していることを確認します。実際の認証済みインターフェイスを通じて、ヘルスチェックと変更されたユーザーパスを確認し、関連するエラーシグナルも調べます。スキーマ変更がある場合は、通常のマイグレーション台帳に保留中のマイグレーションやドリフトがないことを確認します。
インストール済みプラグイン	マーケットプレイスのコピーだけでなく、ユーザーが実際に有効化している登録／キャッシュを特定します。変更されたソース／配布アーティファクトを比較し、新しいツール接続を開きます。実行中のワーカーのバージョン／パスを有効なインストールと比較します。キャッシュが更新済みでも、古いプロセスと通信している場合があります。許可されている場合は、影響を受けるインストール／アップグレードの受け渡しをテストします。フックやウォッチャーの設定は、実際のプロジェクト／ランタイムのスコープで確認します。実際にテストしていない動作には、未検証のラベルを付けてください。

claude-mem の検索リリースでは、Smart 検索を 3 回の独立した呼び出しとしてテストしてください。インデックスの検索、コンテキスト取得のためのタイムライン、選択したレコードのみを対象とする get_observations をそれぞれ実行します。利用可能な場合は、オプションの dumb_search も明示的にテストします。また、それらの配信面がリリースに含まれている場合は、新しいローカルおよびホステッド MCP 接続を通じて、読みやすい無効な入力のガイダンスを確認してください。Smart がデフォルトであること、自動モードやガイド付きモード、継続カーソルが公開されていないこと、ツールの結果が簡潔なテキストであり、純粋な JSON や重複した構造化メタデータを含まないことを検証します。明示的なテスト範囲に書き込みが含まれていない限り、プローブは読み取り専用にしてください。認証情報や非公開の結果本文は決して表示しないでください。

公開は、コマンドが成功した後も遅れることがあります。特定バージョンの 404 や古い配布タグが確認された場合は、レジストリの状態が一致するまで保留のままにしてください。回数を制限して再試行し、再公開する前に実際の公開先／ステータスを調査します。警告だけではリグレッションとは言えません。最終的なアーティファクトを検証してください。同様に、自動公開ジョブの失敗が、検証済みで許可された手動公開によって解消されている場合があります。その場合も、ワークフローの失敗は別の調査結果として記録してください。

観察と修復

• 指定された観察期間を守ってください。指定がない場合は、リリースが初めて一般公開された時点、または本番環境の準備が整った時点のうち、影響を受けるサーフェスで遅い方から30分後まで監視します。以前のリリースの場合は、新たに一通り確認し、該当期間を対象とする完了済みの遅延 CI とレポートを調べてください。
• 保留中または変化しているチェックは30～60秒ごとに確認し、安定したシグナルは2～5分ごとに確認します。ユーザーの指示や進捗の更新にすぐ対応できるよう、個々の待機時間は最大60秒にしてください。API を利用できない場合は、カバレッジの不足であり、リリースが健全である証拠ではありません。
• コードを変更する前に、各検出事項を検証してください。リリースのリグレッション、既存の問題、運用上の失敗、解消済みまたは一時的なシグナルを区別し、それぞれに固有の証拠と次のアクションを提示してください。
• 変更範囲を絞って修正し、変更内容に応じたチェックを実行して、リポジトリで通常使用する PR／リリース／デプロイのプロセスに従ってください。修正 PR には babysit を、新しい claude-mem リリースが承認された場合には version-bump を使用してください。公開済みのバージョンと既存のタグは変更しないでください。
• 修正が反映された後は、変更された配信サーフェスの観察を再開し、影響を受けるユーザーパスを再実行してください。無関係な worktree、ワーカー、登録情報、ユーザー設定、推論／プロバイダーポリシーはそのまま維持してください。
• インフラストラクチャの障害が繰り返し発生する場合や、通知 Webhook が削除されている場合は、具体的なフォローアップが必要です。原因と担当者のアクションを記録して保留状態にし、同じ処理を何度も再試行したり、別の宛先に成功を報告したりしないでください。

証拠を添えて完了する

関連する CI が確定し、配信された成果物と影響を受けるユーザーパスが正常に動作し、対応が必要なリリースのリグレッションが残っておらず、観察期間を満たした時点で完了とします。報告前に、最後にもう一度新たに一通り確認してください。

必須のチェックを完了できない場合は、カバレッジの不足と次のアクションを明記し、リリースを部分検証済みとして報告してください。外部要因でブロックされている運用上のフォローアップは、検証済みの製品の健全性とは分けてください。どちらも暗黙に解決済みとして扱わないでください。

用途に合わせた簡潔なテキストを返してください。リリース／タグ／デプロイの識別情報、チェック内容と観察時刻、検証済みの検出事項と修正内容、保留事項を含めてください。モデル向けの出力に、未加工の API エンベロープ、内部メタデータ、ログ全体を含めないでください。必要に応じて、簡潔な記録へのリンクを付けてください。