olonok69/cursor_code_ml_engineer

day — 稼働日の開始と終了

なぜこれがスキルなのか、単なるドキュメントではないのか。 「開始時にプル、終了時にプッシュ」というルールは運用ドキュメントに数ヶ月間書かれていましたが、出版者マシンで守られていませんでした。同期が記録されないため、ずれを確認できなかったのです。ドキュメントは習慣を強制できませんが、呼び出し可能なルーチンは可能です。以下は、コマンドではなく構造を読んでください。危険なステップはすべて最初に質問に答え、答えがあいまいな場合は停止して質問します。

共有記録（data/ 下）は、最後の同期時点の情報であり、それ以外に更新を促すものはありません。2つの主要なタイミングをパッケージ化しました：

day start     # チームの最新情報を取得し、短いオリエンテーションブリーフィングを実施
day end       # 今日の作業を公開し、コーパスが変更された場合はKGにフラグを立てる
day status    # 各マシンで最近プル/プッシュした人、KGバトンを保持している人を表示
day baton     # 出版者の役割を別のマシンに移動（出張、休暇、引き継ぎ）

以下はすべて macOS、Linux、WSL で動作します — プレーンな bash のみで、PowerShell は使用しません。 スクリプトのコピーは ejemplos/metodologia/s3-sync/ にあります（config.env.example から始めてください — 実際の config.env を絶対に出荷しないでください）。

ステップ 1 — 同期フォルダを見つけてこのマシンの役割を読む

役割によって、実行できる操作が決まります。バケットへの書き込み前に読み取ってください。

S3=""
d="$PWD"
while [ "$d" != "/" ]; do
  if [ -f "$d/data/changes/s3-sync/data-pull.sh" ]; then S3="$d/data/changes/s3-sync"; break; fi
  d="$(dirname "$d")"
done
if [ -z "$S3" ]; then echo "このリポジトリに共有記録同期がありません（<your-repo> ルートで開いてください）。"; fi
sed -n '1,20p' "$S3/IDENTITY.md"

IDENTITY.md がないか、古いように見えますか？再生成してください — これはエージェントが自分の役割を学習するために読むもので、古いカードは一度、削除されたAWSプロファイルを指定していました：

(cd "$S3" && ./identity.sh --write)

S3 が空の場合は、このリポジトリには共有記録がないことをユーザーに伝えて、停止してください。

ステップ 2 — day start

1. ⚠️ まず未公開のローカル作業を確認してください — プルで上書きされる可能性があります。 aws s3 sync は、リモートが新しい場合だけでなく、サイズが異なる場合に転送するため、プルはローカルで編集したファイルをバケットの古いコピーで置き換え、ローカルで名前を変更したものを古い名前で再作成します。--delete は必要ありません。

   (cd "$S3" && ./data-push.sh --root changes)   # ドライラン — リストされたものはローカルのみの作業
   

   --root changes はスイープを日々移動する唯一のルートに限定します（測定値 212秒 → 123秒: 桁違いではなく、トリミングです）。このチェックには問題ありません。公開時にはフルスイープを使用してください。

   何もリストされない → 続行します。何かリストされた → 内容を伝え、先に公開するオプションを提案してください。ユーザーの明確な同意なしに、それを超えてプルしないでください。

2. プル。 決して --delete を使用しないでください。スクリプトは保護しますが、その内容を読む必要があります。

   (cd "$S3" && ./data-pull.sh --go)
   

   適用する前にドライランを実行し、プルで置き換えられるすべてのローカルファイルのスナップショットを data/_prepull/<timestamp>/ に作成し、それらをリストします。対応すべき2つの結果：

   • "⚠️ N 個の既存のローカルファイルが置き換えられます" — そのリストをユーザーに読み上げてください。 共有ハブファイル（STATUS.md、FOLLOWUPS.md、SHARP_EDGES.md、TEST_MAP.md、_RESUME_*.md）がそこに表示される場合、同僚のコピーがあなたのコピーの上に配置されることを意味し、各サイドには相手が欠いているコンテンツが含まれている可能性があります — 勝者を決めるのではなく、マージが必要です。 他のことをする前に、スナップショットと新しいファイルを比較してください： diff data/_prepull/<ts>/changes/STATUS.md data/changes/STATUS.md プル全体を元に戻すには： cp -a data/_prepull/<ts>/. data/
   • 終了コード 3、「大文字小文字が衝突するファイル」 — 2つのバケットオブジェクトが大文字小文字のみ異なり、このマシン上の1つのファイルにマップされます。停止してください。 プルはランダムに勝者を選びます。最初にバケット内の間違った大文字小文字のキーを削除してください。チケットドキュメントの標準的な大文字小文字は小文字の sst-NNNN.md（プレースホルダーパターン）です。

   認証情報エラー？ 結論を出す前に再ログインしてください — 期限切れのキャッシュされたトークンは、権限の問題とまったく同じように見えます： aws sso logout && aws sso login

3. 他の誰がアクティブかを確認： (cd "$S3" && ./activity.sh)

3b. チケットステータステーブルを更新（数秒; 最大5行 — ブリーフィングに貼り付けます）。オプション：プロジェクトがトラッカーとGitホストから生成されたステータステーブルを維持している場合のみ。

(cd "$(dirname "$S3")/tools" && uv run -q --with openpyxl python ticket_status/sync.py)

出版者：Jira（ステータス、タイプ、リンク）とGitHub（PR、マージ日、最初のリリース）からステータスワークブックとそれから生成された .md を書き換えます。コントリビューター：同じ概要ですが、何も書き込みません — 2人の書き込み者がいるバイナリワークブックは最後に書き込んだ人が勝ちます。skipped — workbook is open → ユーザーにワークブックを閉じて再実行するように依頼してください。CANARY FAILED → 何も書き込まれませんでした。他のことをする前に実行ログを読んでください。

3c. 過去24時間のサービス障害（約1分; カウントのみ、ダウンロードは行いません — グループ行をブリーフィングに貼り付けます）：

T="$(dirname "$S3")/tools/evidence"
(cd "$T" && uv run -q --with boto3 python evidence.py discover --env dev --since 24h --list; \
            uv run -q --with boto3 python evidence.py discover --env stg --since 24h --list)

--list は、最初の実稼働実行で dev に24時間で約240件の問題実行が見つかったために存在します。ダウンロードする discover は毎朝自身の --max-runs ガードに引っかかります。終了コード 2 → 最初に再ログイン。終了コード 6 → バケットが古いバージョンを保持しなくなった：ユーザーに伝えてください。グループの証拠を収集するには、evidence スキルを使用してください（fetch --doc <id>、または --list なしの discover --since 2h）。

4. オリエンテーション — 履歴が先、ステータスが後。 最新の data/changes/_RESUME_*.md（古い日: _PENDING_*.md）、次に担当エリアの data/changes/STATUS.md、次に git fetch --all --prune と git status -sb。新しいものを設計する前に、kg スキルを使用して先行事例を確認してください — 最初のステップとして data/changes/ を grep しないでください。

5. 出版者マシンのみ（IDENTITY.md に PUBLISHER と記載）：バトンとリフレッシュキューを確認してください。

   (cd "$S3" && ./publisher.sh status)
   bash data/knowledge-graph/kg_refresh.sh queue
   (cd "$S3" && ./delete.sh --check)            # 復活した削除ファイル（レポートのみ）
   

   保留中の内容を報告してください。求められずにリフレッシュを開始しないでください — 約100の命名判断と丸1時間かかり、半分だけ名前が付けられたグラフはどのゲートも通過しません。

6. 数行でユーザーにブリーフィングし、停止します。day start はマシンを準備します。作業を選択するわけではありません。

ステップ 3 — day end

1. 公開する前に今日の作業を書き留めてください： data/changes/<ticket>/ 下のチケットドキュメント、STATUS.md の行、FOLLOWUPS.md のフォローアップなど。文書記録のない作業は、行われなかった作業と区別がつきません。

2. プレビューし、ファイルリストを読んでください。 これはサニタイゼーションのタイミングです — キー、シークレット、共有記録に入れるべきでないものがないことを確認します。

   (cd "$S3" && ./data-push.sh)
   

   ⚠️ フィクスチャファイル（フィクスチャ / イシュー / サンプルディレクトリ下の .docx/.pdf）に注意してください。抽出ツールの実行はフィクスチャをその場で再保存し、再保存されたフィクスチャは正確なバイトサイズを維持しながらハッシュが変更される可能性があります。バケットの元のコピーを上書きしないでください — 代わりにバケットから自分のコピーを復元してください。

3. 公開。 決して --delete を使用しないでください。

   (cd "$S3" && ./data-push.sh --go)
   

   knowledge-graph/ をスキップしたと報告するコントリビュータープッシュは、エラーではなく正しい動作です — コントリビューターマシンからは refresh_queue/ のみがアップロードされます。

   ⛔ プッシュが終了コード 4 で終了した場合 — 「拒否: 共有ハブファイルがバケット内で変更されました」 — チームメイトがこのマシンの最後の同期後にそれらのファイルの1つを書き込み、私たちのコピーが異なります。aws s3 sync にはマージがないため、プッシュすると相手のコピーが置き換えられます。名前付きファイルをユーザーに読み上げ、それぞれをバケットコピーと比較し、マージしてください。 自分の判断で --allow-clobber を渡さないでください — これは「ユーザーが私たちのコピーが相手のコピーに優先することを確認した」場合のみです。

   (cd "$S3" && source ./config.env && \
     aws s3 cp "s3://$BUCKET/$PREFIX/changes/STATUS.md" - --profile "$PROFILE" | diff - ../STATUS.md)
   

   2026-09-18 測定：同僚が作業を終了してから4分後のプッシュで、同僚の STATUS.md セクション全体とアクティビティ台帳が破壊されました。このマシンではその後何も問題に見えなかったため、丸一日気づかれませんでした。ガードは、私たちのコピーがバケットのものとバイト単位で同一の場合には発動しません。そのため、プルしたばかりのファイルが衝突することはありません。

4. チケットドキュメントが変更された場合、グラフにフラグを立てて、出版者が再構築が必要であることを認識できるようにします：

   bash data/knowledge-graph/kg_refresh.sh request "<何が変更され、なぜ重要なのか>"
   (cd "$S3" && ./data-push.sh --go)
   

5. 正常に配置されたことを確認： (cd "$S3" && ./activity.sh) — このマシンのプッシュは数分前と表示されるはずです。

day status

(cd "$S3" && ./activity.sh)          # マシンごとの最後のプル/プッシュ
(cd "$S3" && ./activity.sh --log)    # 全イベントストリーム
(cd "$S3" && ./publisher.sh status)  # KGを再構築して公開できる人

⚠️ 記録された内容を報告します。インストゥルメントされたスクリプトを一度も実行したことがないマシンは何も表示しません。記録がないことは、アクティビティがないことの証拠ではありません。

day baton — 出版者の役割の移動

1台のマシンがナレッジグラフを公開します。これは aws s3 sync が最後に書き込んだ人が勝ちでマージがないためです。2人の出版者が互いに手動で作成したコミュニティ名を静かに破壊し合います。バトンはバケット内に保持されるアドバイザリーロックであり、どちらのマシンでも確認できます。

(cd "$S3" && ./publisher.sh status)
(cd "$S3" && ./publisher.sh release)            # 送り出すマシン、最初
(cd "$S3" && ./publisher.sh claim "理由")        # 受け取るマシン、2番目

受け取るマシンは、config.env で MACHINE_ROLE="publisher" を設定し、./identity.sh --write を再実行する必要があります。そうしないと、エージェントは CONTRIBUTOR のまま読み取り、自分が担当するようになった作業を拒否します。claim --force は保持されているバトンを上書きします — 毎回ユーザーに確認してください。

すべてのブランチで有効なルール

• 決して --delete しないでください。 出版者のみ、意図的に、そしてフレッシュプルの直後にのみ使用します。
• 共有ストアからの削除は ./delete.sh（出版者）を使用し、決して aws s3 rm や --delete は使用しないでください — そうしないと、他のマシンが次回のプッシュで再アップロードします。
• コントリビューターから knowledge-graph/ をプッシュしないでください。 ツールがこれを強制します。回避しないでください。
• アクセスエラーを診断する前に再ログインしてください — エラーはキャッシュされたトークンを説明しています。
• 人間が外部へのアクションを所有します。 このスキルは共有記録を同期します。ブランチをプッシュしたり、PRを開いたり、デプロイしたり、メッセージを送信したりしません。