충돌, 보드 교체, 또는 3교대의 “빠른 손질” 뒤 팀은 어떤 로봇 프로그램이 돌아야 하는지 말할 수 없음을 발견한다. 펜던트는 무언가를 보여준다. 노트북 폴더는 비슷한 이름의 파일 셋을 보여준다. 생산은 어느 것에도 깔끔히 맞지 않는 스크랩을 보여준다.
로봇 재커미셔닝 체크리스트와 TCP 검증 시트는 어떤 프로그램을 복원하는지 안다고 가정한다. 이 노트는 로봇 프로그램 백업과 개정 규율—오프라인 마스터, 명명, 복원 증거다. 에너지 체인 케이블 마모, 앱솔루트 엔코더 배터리 소실, 사이클 타임 폭포 분석이 아니다.
작동하는 체계는 일부러 지루하다.
- 셀·제품군당 마스터 하나, 펜던트 밖에 두고 파일명과 프로그램 주석에 개정 ID.
- 경로·속도·I/O 수정에 대한 변경 관리—누가 무엇을 왜 바꿨고 어떤 개정이 활성인지.
- 컨트롤러 사건 후 복원 훈련: 마스터 로드, OEM이 허용하면 체크섬·바이트 비교, 부품 전 드라이 사이클 게이트.
- 펜던트는 런타임 사본, 아카이브가 아니다. 유일한 사본으로 취급하면 금요일 손질이 월요일 미스터리가 된다.
오프라인 백업을 건너뛰는 사이트는 첫 죽은 컨트롤러에서 배운다. 날짜 찍힌 마스터와 짧은 복원 절차를 유지하는 사이트는 부족 기억으로 모션을 재구성하지 않고 셀을 살린다. 지금 현장에서 개정을 이름 대지 못하면 버전 관리가 없다—티치 펜던트가 달린 민속이다.