olonok69/cursor_code_ml_engineer

day — 근무일 열기 및 닫기

이것이 스킬인 이유 (단순 문서가 아닌). "시작할 때 풀(pull), 끝날 때 푸시(push)" 규칙이 운영 문서에 몇 달 동안 있었지만 퍼블리셔 머신에서 지켜지지 않았습니다 — 동기화가 기록되지 않아 표류(drift)를 확인할 수 없었습니다. 문서로는 습관을 강제할 수 없지만, 호출 가능한 루틴은 가능합니다. 명령어 자체보다 구조를 읽으세요: 모든 위험한 단계는 먼저 질문을 하고, 답이 모호하면 멈추고 묻습니다.

data/ 아래의 공유 기록은 마지막 동기화 시점까지만 최신 상태이며, 다른 어떤 것도 이를 촉발하지 않습니다. 두 가지 시점이 패키징되어 있습니다:

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. ⚠️ 먼저 게시되지 않은 로컬 작업이 있는지 확인하세요 — 풀(pull)이 이를 덮어쓸 수 있습니다. aws s3 sync는 원격이 더 최신일 때뿐만 아니라 크기가 다를 때마다 전송하므로, 풀은 로컬에서 편집한 파일을 버킷의 오래된 사본으로 교체하고 로컬에서 이름을 바꾼 모든 항목을 이전 이름으로 다시 생성합니다. --delete는 필요하지 않습니다.

   (cd "$S3" && ./data-push.sh --root changes)   # 드라이 런 — 나열된 것은 로컬 전용 작업
   

   --root changes는 스윕(sweep)을 매일 움직이는 유일한 루트로 제한합니다 (212초 → 123초: 크게 줄이지는 않지만, 자리 잡은 개선). 이 확인에는 충분합니다. 게시할 때는 전체 스윕을 사용하세요.

   아무것도 나열되지 않음 → 계속 진행. 무언가 나열됨 → 무엇인지 말하고 먼저 게시할 것을 제안하세요. 사용자의 명시적인 동의 없이 이를 무시하고 풀(pull)하지 마세요.

2. 풀(Pull). 절대 --delete를 사용하지 마세요. 스크립트가 이제 보호하지만, 스크립트가 말하는 내용을 읽어야 합니다.

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

   적용하기 전에 드라이 런을 수행하고, 풀이 대체할 모든 로컬 파일을 data/_prepull/<timestamp>/에 스냅샷한 후 나열합니다. 조치해야 할 두 가지 결과:

   • "⚠️ 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, "대소문자 충돌 파일(CASE-COLLIDING FILES)" — 두 버킷 객체가 대소문자만 다르며 이 머신에서 하나의 파일로 매핑됩니다. 중지하세요. 풀이 무작위로 승자를 선택합니다. 먼저 버킷에서 잘못된 대소문자 키를 삭제하세요. 티켓 문서의 표준 대소문자는 소문자 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를 다시 작성합니다. 기여자: 동일한 요약, 아무것도 쓰지 않음 — 두 명의 작성자가 있는 이진 워크북은 마지막 작성자가 승리합니다. 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. 무언가를 설계하기 전에 선행 사례(prior art)를 위해 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. 미리보기 및 파일 목록 읽기. 이것은 정리(sanitisation) 순간입니다 — 키, 비밀, 공유 기록에 들어가면 안 되는 것은 없어야 합니다.

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

   ⚠️ 고정 파일(fixture files)(.docx/.pdf가 fixture / issue / sample 디렉토리 아래에 있는 경우)을 주의하세요. 추출기 실행은 고정 파일을 제자리에 다시 저장하며, 다시 저장된 고정 파일은 정확한 바이트 크기를 유지하면서 해시가 변경될 수 있습니다. 버킷의 원본 사본을 덮어쓰지 마세요 — 대신 버킷에서 사본을 복원하세요.

3. 게시(Publish). 절대 --delete를 사용하지 마세요.

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

   knowledge-graph/를 건너뛰었다고 보고하는 기여자 푸시는 오류가 아니라 정상입니다 — refresh_queue/만 기여자 머신에서 올라갑니다.

   ⛔ 푸시가 종료 코드 4로 종료되는 경우 — "거부됨: 공유 허브 파일이 버킷에서 변경됨(REFUSED: shared hub file(s) changed in the bucket)" — 팀원이 이 머신이 마지막으로 동기화한 후 해당 파일 중 하나를 작성했으며, 우리 사본이 다릅니다. aws s3 sync에는 병합 기능이 없으므로 푸시가 그들의 파일을 대체합니다. 명명된 파일을 사용자에게 소리내어 읽고, 각각을 버킷 사본과 비교(diff)한 후 병합하세요. 스스로 --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 섹션과 활동 원장(activity ledger)을 파괴했습니다 — 그리고 이 머신에서는 이후에 아무 문제가 없어 보여서 하루 종일 눈에 띄지 않았습니다. 가드는 우리 사본이 버킷의 사본과 바이트가 동일할 때는 작동하지 않으므로, 방금 풀(pull)한 파일은 결코 충돌이 아닙니다.

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 — 퍼블리셔 역할 이관

하나의 머신만 지식 그래프를 게시합니다. aws s3 sync는 마지막 작성자가 승리하며 병합이 없기 때문입니다: 두 명의 퍼블리셔가 서로가 수동으로 작성한 커뮤니티 이름을 조용히 파괴합니다. 배턴(baton)은 버킷에 보관되는 조언적 잠금(advisory lock)으로, 두 머신 모두 확인할 수 있습니다.

(cd "$S3" && ./publisher.sh status)
(cd "$S3" && ./publisher.sh release)            # 보내는 머신, 먼저 실행
(cd "$S3" && ./publisher.sh claim "이유")        # 받는 머신, 그다음 실행

받는 머신은 또한 config.env에서 MACHINE_ROLE="publisher"를 설정하고 ./identity.sh --write를 다시 실행해야 합니다. 그렇지 않으면 에이전트가 계속 CONTRIBUTOR를 읽고 이제 소유한 작업을 거부합니다. claim --force는 보유된 배턴을 무시합니다 — 매번 사용자에게 확인하세요.

모든 브랜치에서 적용되는 규칙

• 절대 --delete를 사용하지 마세요. 퍼블리셔 전용, 신중하게, 그리고 신선한 풀 직후에만 사용합니다.
• 공유 저장소에서 삭제는 ./delete.sh (퍼블리셔)를 사용하며, 절대 aws s3 rm이나 --delete를 사용하지 마세요 — 그렇지 않으면 다른 머신이 다음 푸시에서 다시 업로드합니다.
• 기여자는 절대 knowledge-graph/를 푸시하지 마세요. 도구가 이를 강제합니다. 우회하지 마세요.
• 접근 오류를 진단하기 전에 다시 로그인하세요 — 오류는 캐시된 토큰을 설명합니다.
• 인간(human)이 외부 작업을 소유합니다. 이 스킬은 공유 기록을 동기화할 뿐입니다. 브랜치를 푸시하거나, PR을 열거나, 배포하거나, 메시지를 보내지 않습니다.