문제
자동화 작업을 오래 운영하면 종료된 세션 이름, 죽은 프로세스의 껍데기, 과거 작업 디렉터리가 남는다. 이름만 보고 “이미 누군가 이 일을 하고 있다”고 판단하면 필요한 작업을 영원히 미루게 되고, 반대로 이름만 오래됐다고 지우면 아직 살아 있는 작업자의 변경을 파괴할 수 있다. 목록에 존재한다는 사실과 지금 실행 중이라는 사실은 전혀 다른 증거다.
운영 패턴
1. 소유권을 판단하기 전에 세션이나 프로세스의 생존 플래그를 확인한다. 이름이 있어도 종료 상태라면 활성 소유자가 아니다.
2. 살아 있다면 현재 작업 디렉터리가 대상 저장소의 전용 작업 공간인지 확인한다. 같은 이름이 다른 프로젝트를 가리킬 수 있다.
3. 현재 명령이 실제 작업 명령인지, 단순 대기 셸인지 구분한다. 프로세스가 존재해도 일을 수행 중이라는 뜻은 아니다.
4. 저장소의 변경 상태와 원격 기준점을 확인한다. 살아 있는 작업자가 가진 변경이 있다면 다른 실행자는 쓰기를 시작하지 않는다.
5. 이름, 생존 상태, 경로, 명령, 변경 소유권을 한 묶음의 증거로 기록한 뒤에만 재사용·대기·정리 중 하나를 선택한다.
왜 중요한가
중복 실행은 같은 파일을 서로 다른 판단으로 수정하고, 배포나 알림을 두 번 수행하며, 어느 결과가 정본인지 흐린다. 반대로 성급한 정리는 복구 가능한 작업 공간을 없애고 조사 증거까지 지운다. 몇 초짜리 생존 확인은 두 종류의 실패를 모두 막는 가장 싼 안전장치다.
완료 기준
활성 소유자가 있다고 보고 기다리거나, 죽은 세션이라고 보고 정리하기 전에 생존 상태·작업 경로·현재 명령·저장소 변경을 모두 확인했다면 완료다. 판단 근거가 하나라도 모호하면 삭제나 새 쓰기를 시작하지 말고, 읽기 전용 확인을 계속한다.
Problem
Long-running automation leaves behind session names, dead process shells, and old working directories. Treating a name as proof that someone is still working can block necessary work forever; deleting it merely because it looks old can destroy a live worker’s changes. Presence in a list and active ownership are different claims that require different evidence.
Operating pattern
1. Check the session or process liveness flag before assigning ownership. A named but terminated entry is not an active owner.
2. If it is alive, verify that its working directory is the dedicated workspace for the target repository; similar names can point elsewhere.
3. Distinguish an actual work command from an idle shell. A process can exist without performing the task.
4. Inspect repository changes and the remote baseline. If a live worker owns uncommitted changes, another executor must not begin writing.
5. Record name, liveness, path, command, and change ownership as one evidence bundle before choosing to reuse, wait, or clean up.
Why it matters
Duplicate execution edits the same files under competing assumptions, repeats deployments or notifications, and makes the canonical result unclear. Premature cleanup destroys recoverable work and may erase the evidence needed to understand a failure. A few seconds of liveness checking is the cheapest guard against both errors.
Completion bar
Before waiting on an alleged owner or removing an allegedly dead session, verify liveness, working path, current command, and repository changes. If any part remains ambiguous, avoid deletion and new writes; continue with read-only inspection until ownership is proven.
问题
长期运行的自动化会留下旧会话名、已死亡进程的外壳和过去的工作目录。仅凭名字就认定“已经有人在处理”，可能让必要工作无限期搁置；仅凭名字看起来陈旧就删除，又可能破坏仍在运行的工作者所持有的改动。出现在列表中和实际拥有任务，是两个需要不同证据的判断。
运行模式
1. 在判断所有权之前，先检查会话或进程的存活标志；有名字但已结束的条目不是活跃所有者。
2. 如果仍存活，确认其工作目录确实是目标仓库的专用工作区，相似名称可能指向别处。
3. 区分真正的工作命令和空闲 shell；进程存在不代表任务正在执行。
4. 检查仓库改动和远端基线。若活跃工作者持有未提交改动，另一个执行者不得开始写入。
5. 将名称、存活状态、路径、命令和改动归属作为一组证据记录后，再决定复用、等待或清理。
为什么重要
重复执行会让多个执行者基于不同判断修改同一文件，重复部署或通知，并使哪个结果才是规范版本变得不清楚。过早清理则会毁掉可恢复的工作区，甚至删除调查失败所需的证据。几秒钟的存活检查，是同时避免这两类错误的最低成本防线。
完成标准
在等待所谓的任务所有者或删除所谓的死亡会话之前，已核实存活状态、工作路径、当前命令和仓库改动，才算完成。如果其中任何一项仍不明确，就不要删除也不要开始新的写入，应继续只读检查直到所有权得到证明。
問題
長期運用する自動化には、終了したセッション名、死んだプロセスの殻、以前の作業ディレクトリが残る。名前だけで「すでに誰かが担当している」と判断すると必要な作業が止まり続け、古そうだという理由だけで削除すると、まだ稼働中の担当者の変更を壊しかねない。一覧に存在することと、現在の所有者であることは別の主張であり、別の証拠が必要だ。
運用パターン
1. 所有権を判断する前に、セッションやプロセスの生存フラグを確認する。名前があっても終了済みなら現役の担当者ではない。
2. 生きている場合は、作業ディレクトリが対象リポジトリ専用の作業領域か確認する。似た名前が別の場所を指すこともある。
3. 実作業のコマンドと待機中のシェルを区別する。プロセスの存在だけではタスク実行中とは言えない。
4. リポジトリの変更とリモート基準点を確認する。稼働中の担当者が未コミット変更を持つなら、別の実行者は書き込みを始めない。
5. 名前、生存状態、パス、コマンド、変更の所有権を一組の証拠として記録してから、再利用・待機・片付けを選ぶ。
なぜ重要か
重複実行は異なる前提で同じファイルを編集し、デプロイや通知を繰り返し、どの結果が正本なのかを曖昧にする。早すぎる片付けは復旧可能な作業を壊し、障害を調べる証拠まで消す。数秒の生存確認は、両方の失敗を防ぐ最も安価な安全策である。
完了基準
担当者を待つ、または死んだセッションを削除する前に、生存状態、作業パス、現在のコマンド、リポジトリ変更をすべて確認できていれば完了だ。一つでも曖昧なら削除や新しい書き込みをせず、所有権が証明されるまで読み取り専用の確認を続ける。