day — 開啟和關閉工作日

為什麼這是一項技能，而不只是一個文件。 「開始時拉取，結束時推送」的規則存在於操作文件中長達數月，但在發布者機器上並未被遵循——沒有任何東西記錄同步，因此無從顯示偏差。文件無法強制養成習慣；但可呼叫的例行程序可以。請閱讀此內容以了解形狀，而非命令：每個危險步驟都會先提出一個問題，當答案不明確時，它會停止並詢問。

位於 data/ 下的共用記錄，其時效性完全取決於最近一次同步，而且沒有其他東西會提示它。兩個關鍵時刻，已打包：

day start     # 拉取團隊最新資料，然後進行簡短的定向簡報
day end       # 發布今天的工作，如果語料庫有變動，則標記知識圖譜
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`

⚠️ 先檢查是否有未發布的本地工作——拉取作業可能會覆蓋它。 aws s3 sync 在大小不同時就會傳輸，而不僅僅是遠端較新時，因此拉取作業會用儲存桶中較舊的副本替換本地編輯過的檔案，並以舊名稱重新建立你在本地重新命名的任何內容。不需要 --delete。
```
(cd "$S3" && ./data-push.sh --root changes)   # 試執行——任何列出的內容都是僅限本地的工作
```
--root changes 將掃描範圍限制在唯一每天都在變動的根目錄（測量結果 212 秒 → 123 秒：是縮減，非數量級差異）。此檢查適用；發布時請使用完整掃描。

沒有列出任何內容 → 繼續。列出了一些內容 → 說明它是什麼並提供先發布的選項；在沒有使用者明確同意的情況下，不要繞過它進行拉取。
拉取。 永遠不要使用 --delete。腳本現在會保護你，但你必須閱讀它說的話。
```
(cd "$S3" && ./data-pull.sh --go)
```
在應用任何內容之前，它會先進行試執行，將拉取作業將要取代的每個本地檔案的快照放入 data/_prepull/<timestamp>/，並列出它們。有兩種結果需要採取行動：
- "⚠️ N 個現有本地檔案將被 REPLACED" — 向使用者大聲讀出該清單。共用中樞檔案（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，"CASE-COLLIDING FILES" — 兩個儲存桶物件僅在大小寫上不同，並對應到本機上的一個檔案。停止。 拉取作業會隨機選擇一個贏家。首先在儲存桶中刪除大小寫錯誤的 key；票證文件的正規大小寫是小寫 sst-NNNN.md（佔位符模式）。
憑證錯誤？在得出任何結論之前先重新登入——一個過期的快取令牌看起來完全像是一個權限問題：aws sso logout && aws sso login。
查看還有誰活躍： (cd "$S3" && ./activity.sh)

3b. 重新整理票證狀態表格（幾秒鐘；≤ 5 行——將它們貼到簡報中）。可選：僅當專案維護從追蹤器 + Git 主機產生的狀態表格時。

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

發布者：重新寫入狀態工作簿以及從它產生的 .md，資料來自 Jira（狀態、類型、連結）和 GitHub （PR、合併日期、首次發布）。貢獻者：相同的摘要，不寫入任何內容——一個二進位工作簿有兩個寫入者是「最後寫入者贏」。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 個問題執行：一個下載發現會在每天早上觸發自己的 --max-runs 保護。退出 2 → 先重新登入。退出 6 → 儲存桶停止保留舊版本：告訴使用者。要收集某個群組的證據，請使用 evidence 技能（fetch --doc <id>，或 discover --since 2h 但不加 --list）。

導向——先看歷史，再看狀態。 最新的 data/changes/_RESUME_*.md（較舊的日期：_PENDING_*.md），然後是你所在區域的 data/changes/STATUS.md，然後是 git fetch --all --prune 和 git status -sb。在設計任何東西之前，請先使用 kg 技能查找先前成果——永遠不要將對 data/changes/ 的 grep 當作第一步。
僅限發布者機器（IDENTITY.md 顯示 PUBLISHER）：檢查接力棒和重新整理佇列。
```
(cd "$S3" && ./publisher.sh status)
bash data/knowledge-graph/kg_refresh.sh queue
(cd "$S3" && ./delete.sh --check)            # 再次出現的已刪除檔案（僅報告）
```
報告待處理的項目；在未經要求的情況下不要啟動重新整理——這大約是 ~100 個命名判斷和整整一小時，而一個命名一半的圖譜無法通過任何關卡。
用幾行向使用者簡報，然後停止。day start 準備機器；它不會選擇工作。

步驟 3 — `day end`

在發布之前先寫下今天的工作：位於 data/changes/<ticket>/ 下的票證文件，STATUS.md 中的一行，FOLLOWUPS.md 中的任何後續事項。沒有書面記錄的工作與從未發生過的工作無法區分。
預覽，並閱讀檔案清單。 這是清理的時刻——沒有金鑰、沒有機密、沒有不應進入共用記錄的內容。
```
(cd "$S3" && ./data-push.sh)
```
⚠️ 注意測試檔案（fixture / issue / sample 目錄下的 .docx/.pdf）。提取器執行會就地重新儲存測試檔案，而重新儲存的測試檔案可以保持其確切的位元組大小，同時其雜湊值發生變化。不要推送到儲存桶的原始副本之上——改為從儲存桶恢復你的副本。
發布。 永遠不要使用 --delete。
```
(cd "$S3" && ./data-push.sh --go)
```
一個貢獻者的推送報告它跳過了 knowledge-graph/ 是正確的，而不是錯誤——只有 refresh_queue/ 會從貢獻者機器上傳。

⛔ 如果推送退出 4 — "REFUSED: shared hub file(s) changed in the bucket" — 一個隊友在上次同步之後寫入了其中一個檔案，而我們的副本不同。 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：同事關閉他的一天四分鐘後的一次推送，摧毀了他整個 STATUS.md 部分和他的活動分類帳——而此機器上的內容之後看起來並沒有問題，因此整整一天都未被注意。當我們的副本與儲存桶的副本在位元組上相同時，此保護不會觸發，因此我們剛剛拉取的檔案永遠不會發生衝突。

如果票證文件發生變更，請標記圖譜，以便發布者知道需要重建：

bash data/knowledge-graph/kg_refresh.sh request "<什麼變更了以及為什麼重要>"
(cd "$S3" && ./data-push.sh --go)

確認它已落地： (cd "$S3" && ./activity.sh) — 此機器的推送時間戳應為幾分鐘前。

`day status`

(cd "$S3" && ./activity.sh)          # 每台機器的最近拉取/推送
(cd "$S3" && ./activity.sh --log)    # 完整事件串流
(cd "$S3" && ./publisher.sh status)  # 誰可以重建和發布 KG

⚠️ 它報告的是已記錄的內容。從未執行過受控腳本的機器不會顯示任何內容；沒有記錄並不表示沒有活動。

`day baton` — 移動發布者角色

一台機器發布知識圖譜，因為 aws s3 sync 是「最後寫入者贏」且沒有合併功能：兩個發布者會默默地摧毀彼此手寫的社群名稱。接力棒是儲存在儲存桶中的建議性鎖定，因此任一機器都可以檢查它。

(cd "$S3" && ./publisher.sh status)
(cd "$S3" && ./publisher.sh release)            # 離開的機器，首先執行
(cd "$S3" && ./publisher.sh claim "why")        # 接手的機器，第二個執行

接收機器還必須在 config.env 中設定 MACHINE_ROLE="publisher" 並重新執行 ./identity.sh --write，否則其代理程式會繼續讀取 CONTRIBUTOR 並拒絕它現在擁有的工作。claim --force 會覆蓋持有的接力棒——每次都需與使用者確認。

在所有分支中都適用的規則

永遠不要使用 --delete。 僅限發布者、經審慎考慮，並且僅在剛完成拉取之後使用。
從共用儲存中刪除是 ./delete.sh（發布者）的工作，永遠不要使用 aws s3 rm 或 --delete—— 否則其他機器會在下次推送時再次上傳它。
永遠不要從貢獻者機器推送 knowledge-graph/。 工具會強制執行此規則；不要繞過它。
在診斷存取錯誤之前先重新登入——錯誤描述的是你的快取令牌。
人類擁有對外行動的所有權。 此技能同步共用記錄；它不會推送分支、開啟 PR、部署或向任何人發送訊息。

olonok69/cursor_code_ml_engineer

cursor_code_ml_engineer 是什麼？

在你喜歡的 AI 中提問

說明文件