Repository navigation
[P2][U09] 오류·빈 상태를 구분하고 데이터·초안을 보존하는 재시도와 다음 행동 제공 #629
Description
[P2][U09] 오류·빈 상태를 구분하고 데이터·초안을 보존하는 재시도와 다음 행동 제공
문제와 사용자 결과
활성 홈과 달력은 데이터 조회 실패를 빈 달력 또는 일반 오류 한 줄로 보여주고, 일정 생성·편집의 초기 조회 실패는 로딩을 끝내지 못할 수 있다. 기본 준비 편집은 내부 예외 문자열을 표시한다. 사용자는 일정이 없는지, 아직 읽는 중인지, 읽지 못한 것인지 구분하고 자신의 입력을 유지한 채 안전한 다음 행동을 선택할 수 있어야 한다.
모든 오류에 같은 “다시 저장” 버튼을 붙이는 작업이 아니다. 읽기 재시도, 입력 수정, 최신 일정 확인, 이미 저장된 작업의 알림 후속처리, 실제 권한 설정, 제한된 데이터 복구를 구분한다. 기존 A08/C01/D03의 저장·복원·초기화 결과와 작업 소유권을 보존하며, 원자성이나 완료 여부가 확인되지 않은 작업을 UI만으로 실패 전 상태라고 주장하지 않는다.
- 감사 ID: U09, P2. 연결된 데이터 원자성·읽기 상태 선행 보강은 해당 P1 계약을 따른다.
- 고정 조사 source:
06a238b634a0206f257348db201034fc06eb05c7. - 조사 시점의 A09 미커밋 작업은 읽거나 근거로 사용하지 않았다. 구현 시작 시 최종 커밋 SHA에서 활성 경로와 선행 이슈 결과를 다시 확인한다.
- 이 문서는 요구사항·계약·검증 계획이다. 제품 구현, 실패 주입 실행, 모바일 설정 왕복, 스크린리더 검증 완료 보고가 아니다.
- 전담 신규 서브에이전트
/root/grill_u09가grill-with-docs를 읽고 질문을 하나씩 했으며 root가 사용자를 대신해 답했다. 실제 문답과 정정은 아래에 모두 보존했다.
조사 근거와 감사 내용의 정정
모든 코드 링크는 위의 고정 SHA다. 파일 이름만 보고 비활성 화면을 제품 근거로 삼지 않는다.
| 근거 | 확인된 현재 동작 | U09 판정 |
|---|---|---|
| 활성 router, HomeScreenTmp | /home은 HomeScreenTmp와 MonthlySchedulesBloc을 사용 |
home_screen.dart/WeeklySchedulesBloc에서 본 빈 SizedBox는 활성 제품 결함 증거에서 제외. 최초 질문의 오류는 문답 정정에 보존 |
| 활성 MonthCalendar | status별 loading/error 표시 없이 schedules[day] ?? []로 marker 생성 |
read 실패와 성공-empty 구분, 같은 범위의 마지막 성공 자료 표시와 재시도 필요 |
| 활성 오늘 카드, ScheduleState | initial과 notExists 모두 schedule null로 표시; tile은 noAppointments 렌더 |
최초 미조회≠없음. C08의 nearest 조회 상태 계약으로 loading/error/success-empty 구분 |
| nearest 구독 | stream .listen에 onError 없음 |
U09 별도 조회 엔진이 아니라 C08의 오류·구독 수명 포트 보강 필요 |
| 달력 error, 선택일 콘텐츠 | calendar error는 일반 error; 데이터 없는 non-success는 빈 영역. 성공-empty 오늘/미래에는 이미 Add CTA 존재 | 성공-empty까지 전부 미구현이라는 해석 철회. 기존 CTA 보존, 오류 전용 행동 추가 |
| MonthlySchedulesBloc | refresh는 load만 실행하고 실패 시 error; range load는 requestId·구독 취소 있음(319–407), preparation stream 구독은 onError 없음(43–49), duration read 실패는 null fallback(267–283) | retry를 단순 refresh 호출로 끝내지 말고 현재 실패 범위 재구독/성공 회복까지 검증. 이미 있는 requestId 재사용, 준비자료 실패도 성공 0분으로 추정 금지 |
| 폼 초기 조회 | create/edit draft await에 catch 없음(143–219), loading 이후 예외 시 사용자 read-failure 상태 전환 없음 | 동일 초기 인자·대상·scope의 안전한 재시도, 돌아가기, late load의 draft 덮어쓰기 방지 |
| A08 폼 결과 | owner+mutation+route 확인; deliveryPending·conflict 리뷰·typed failure 존재; initial error는 일반 텍스트(242–245) | 초기 감사의 raw save exception이 그대로라고 주장하지 않는다. 이미 해결된 typed save는 유지, 초기 읽기와 원인별 CTA 연결 보강 |
| generic retry sheet | 모든 전달 message에 같은 Retry saving 사용; caller는 protected도 전달 가능 | protected/validation/unavailable를 같은 재저장으로 취급하지 않음 |
| 기본 준비 Bloc, 오류 dialog | 초기 getDefaultPreparation 미catch; 제출106–108은 preparation write→spareTime write→loadUser 순서; catch는 e.toString을 dialog title로 노출 | raw 예외 제거와 단계별 commit 결과 필요. 첫 write 실패와 두 write 후 read 실패를 구분하는 C01 추가 통합 항목 |
| 반복 관리 | list error 안전 문구+Retry, empty 생성 CTA 이미 있음 | 새로 구현됐다고 세지 않는다. 재시도 중복/late completion/취소·복귀 수명 회귀 검증 |
| onboarding | 제출 예외 catch, 일반 error+OK, finally busy 해제 | 저장 계약을 확인한 뒤 실제 입력 유지/수정/안전 재시도; 미확인 commit에 완전 미저장 문구 금지 |
| My Data | freshness retry, committed 또는 uncommitted cleanup 분리, typed failure 렌더(389–399) 이미 있음 | 기존 C01 결과/receipt 재사용; UI 일관성 개선을 이유로 backup apply를 재실행하지 않음 |
| 알림 설정 | status read single-flight, 실패 상태 문구; timing settings·권한 요청 기존 경로 존재 | 실제 거부 capability에만 설정 CTA, generic DB 오류에는 read retry. 상세 토글 저장 race는 U03 소유 |
| 준비 시작, Recovery | A07 시작 실패 표시·기존 action, recovery retry/reset와 D03 진행 결과 존재 | 별도 retry/reset 엔진 금지; startup restricted mode/손상 DB 복원 D01/D02 의존 |
근거로 읽은 도메인 문서는 CONTEXT.md의 Schedule Draft, Unsaved Schedule Changes, Local Data Store, Recovery Mode, Backup Restore, Preparation Run 및 ADR 0023, ADR 0037다. docs/Error-Handling-Result-System.md의 Result/Failure 설명은 실제 제품 경로에서 일률 적용되었다는 증거가 아니다. 새로운 도메인 용어·되돌리기 어려운 아키텍처 선택을 추가하지 않으므로 새 glossary/ADR는 만들지 않는다.
화면·상태·행동 계약
| 대상과 상태 | 사용자에게 알릴 사실 | 행동과 금지 사항 |
|---|---|---|
| 활성 홈/달력 최초 loading | 일정 정보를 읽는 중 | loading 표시, navigation 가능 범위 유지. noAppointments/0개로 단정 금지 |
| 홈/달력 success-empty | 성공적으로 조회한 그 범위에 일정 없음 | 오늘/미래는 기존 일정 추가 경로. 달력 선택 날짜 유지하여 create. 과거 선택일은 오늘로 이동을 기본 행동으로, 과거 일정 생성 허용 정책 변경 없음 |
| read-error / 성공 자료 없음 | 이 범위의 일정을 확인하지 못함 | 현재 범위 다시 읽기+안전한 돌아가기. reset/빈 profile/네트워크·로그인/권한 설정 제안 없음 |
| read-error / 같은 범위 마지막 성공 자료 있음 | 표시 자료의 최신 상태를 확인하지 못함 | 자료를 stale로 명시하고 날짜/스크롤 유지. 다른 날짜 자료를 현재 자료로 표시 금지. edit/delete/start는 owner/store/현재 권위 read가 통과한 경우에만 실행 |
| 준비 기간 보조 조회 실패 | 준비시간을 확인하지 못함 | unknown과 실제 0분 구분. 해당 읽기 재시도나 상위 안전 안내. 조회 실패를 불필요한 전체 목록 삭제·재생성으로 해결하지 않음 |
| create/edit 초기 load 실패 | 작성/편집에 필요한 정보를 읽지 못함 | 동일 initialDate / id / recurring scope read retry, 돌아가기. reset·새 ID 생성·빈 edit 대체 금지 |
| draft 존재 후 읽기 실패 | 기존 입력은 현재 화면에 유지 | 현재 step/값/포커스 보존. late load/retry completion이 새로운 owner·수정된 입력을 덮지 않음 |
| validation | 수정할 입력과 이유 | 해당 필드/단계로 명시 이동 또는 안전 포커스. owner가 바뀐 뒤 자동 이동 금지. 저장 재시도가 입력 수정 대신 쓰이지 않음 |
| protected save | 시작/완료 등 현재 보호 이유로 변경할 수 없음 | 안전하게 돌아가기/현재 일정 보기. 같은 명령을 무한 재시도시키지 않음 |
| conflict save | 저장 시작점 이후 변경됨 | A08 최신 authoritative review→사용자가 baseline 수락. 초안 유지, 수락 자체가 저장 성공이나 dirty 해제는 아님 |
| 확인된 precommit save failure | 이번 저장이 반영되지 않음, 초안 유지 | typed 계약이 보장할 때만 같은 mutation의 안전 재시도. actual pending 작업의 timeout을 취소 성공으로 취급하지 않음 |
| DB committed + delivery pending | 일정은 저장됨, 알림 설정 후속처리 남음 | 기존 receipt의 retryDelivery만 호출. 일정 재생성/재저장/초안 폐기 경고로 되돌리지 않음 |
| commit 여부 불명확/예상 밖 오류 | 완료 상태를 확인하지 못함 | 권위 결과를 확인하거나 안전 종료 안내. 무조건 rollback/저장 안 됨/다시 저장으로 치환 금지 |
| 기본 준비 첫 write 실패 | 확인된 저장 실패 단계 | 입력 유지+typed 결과별 retry; raw 내부 예외 노출 금지 |
| 기본 준비 일부 write 또는 write 후 user reload 실패 | 실제 반영 상태를 확인해야 함 | C01의 transaction/typed 결과 포트 선행 보강. 이미 반영된 값을 다시 적용하는 generic retry 금지. read 후속처리만 실패했다면 write 재실행 없음 |
| 반복 목록 empty/error | 기존 안내와 원인 구분 | 기존 Add/Retry 유지, busy/single-flight·late completion 검증. 모든 목록이 미구현이라는 주장 금지 |
| onboarding 제출 오류 | 입력을 유지하고 확인된 단계 안내 | 실제 저장 경계에 맞는 수정/재시도. 성공한 부분을 모르는 상태에서 “아무것도 저장되지 않음” 금지 |
| My Data freshness read | 백업 상태를 확인하지 못함 | freshness 읽기만 재시도, export 자동 실행 없음 |
| backup invalid/password/cancel/stale preview | 검증 실패·취소·확인 정보 만료 구분 | 수정/파일 선택/새 검증+preview. 자동 restore apply 금지, password/path/raw 오류 보관 금지 |
| backup restore/reset 후속처리 | committed 또는 uncommitted 및 pending cleanup 사실 | C01/D03/A09/D02의 최신 receipt·journal 사용, restore/전체 삭제 재적용 금지 |
| 알림 권한 거부/차단 | 해당 플랫폼 capability의 실제 제한 | 기존 OS 설정/permission 경로를 명시 동작으로 실행, 복귀 후 재확인. 반복 permission prompt 루프 금지 |
| 알림 DB/status read 오류 | 권한 상태를 확인하지 못함 | read retry. 확인 안 된 권한 거부로 표시하거나 설정을 만능 해결책으로 제공 금지 |
| Preparation Start 오류 | A07의 시작/복구 결과 | 기존 typed 시작·follow-up action 및 owner 경계 유지. U09가 새 Run 생성/자동시작하지 않음 |
| Recovery Mode | 로컬 데이터를 안전하게 열지 못함 | D01/D02 제한 모드의 retry/검증 백업복원/명시 destructive reset만. 일반 오류마다 recovery 진입하거나 자동 삭제 금지 |
읽기 상태는 마지막 성공 데이터의 범위와 현재 요청 범위를 함께 추적한다. retry는 현재 선택 범위에서 한 번만 실행하며 구독을 교체·해제하고, 구 request completion/emission을 요청 identity와 수명으로 거부한다. 사용자가 다른 범위를 선택한 후 old request가 실패하거나 성공해도 현재 화면을 바꾸지 않는다. 닫힌 화면의 콜백이 dialog, navigation, 다른 화면 입력 변경을 일으키지 않는다.
쓰기의 single-flight는 실제 완료 전까지 유지한다. 타임아웃을 부여한 Future가 아직 실행 중인 경우 새로운 write를 겹치게 실행하지 않는다. 읽기 쿼리 교체도 실제 자원·구독 수명을 관리하며 resume/poll/자동재시도 루프로 바꾸지 않는다. transient 오류 표시와 안정된 inline 복구 안내 중 적절한 표현을 선택하되, 오래 걸리는 복구의 유일한 행동이 곧 사라지는 snackbar에만 있지 않게 한다.
오류 code/typed args는 원인·단계·허용 action을 나타내는 최소 데이터다. Domain/Bloc에 BuildContext나 완성된 번역 문구·raw exception을 저장하지 않는다. 사용자 문구는 현재 KO/EN locale에서 렌더하며 stack trace, SQL, DB 경로, 파일 URI, password, 사용자 일정 원문을 오류 안내·진단 문자열에 넣지 않는다. 원래 사용자 입력 필드의 값은 그대로 보존하며 “오류에 원문 노출 금지”를 이유로 입력 자체를 지우지 않는다. 로깅 시스템 신설은 O03 범위다.
의존성과 작업 범위
| 연결 이슈 | U09가 재사용·의존하는 계약 | 별도 완료 경계 |
|---|---|---|
| A08 #601 | atomic save, stable mutation receipt, typed conflict/protected/unavailable, saved+deliveryPending, form/store ownership | A08 구현을 raw save 예외 미해결로 중복 기재하지 않음 |
| C01 #600 | domain workflow와 commit/follow-up 결과 | C01은 이미 부분 구현되었으며 이번 조사에서 확인한 기본 준비의 두 write+loadUser를 추가 통합 미완료 항목으로 추적. 최소 transaction/typed 결과가 필요하며 문구 교체만으로 해결 판정 금지 |
| C08 #610 | nearest 일정의 현재성/clock/stream 수명과 오류 | 활성 오늘 카드 read 상태는 이 포트를 사용. 새 nearest timer/조회 엔진 금지 |
| D03 #595, A09 #602, D01 #603, D02 #604 | cleanup journal/restore result/안전한 startup/손상 DB 복구 | 현재 receipt에만 연결. 별도 초기화·복원 coordinator 금지 |
| U03 #612 | 설정 저장/재등록 실패와 연속 조작 | 토글 저장 알고리즘은 U09에서 중복 구현하지 않음 |
| U05 #626, U06 #627, U07 #628, U08 #597 | 각각 번역, 미저장 이탈 보호, 접근성, 레이아웃 | U09 action의 안전 렌더/초안 유지/접근·배치만 직접 검증; 전체 범위 완료 주장 금지 |
| A07 #599, T01 #615, T02 #616, O03 | Preparation Start receipt, 핵심 E2E/기기 검증, local 진단 | U09 직접 regression과 실제 모바일/AT proof 구분. 원격 로그·로그인·서버 추가 없음 |
구현 문서 작성 시 각 이슈 링크 제목과 state를 재확인한다.
제품 데이터 migration, 새 네트워크 의존성, 무제한 retry, 신규 언어/설정, 자동 백업/복원, background polling, 새 복구 엔진, UI 전면 redesign은 범위 밖이다. 기본 준비 원자성 선행 보강은 기존 C01 포트에 연결한다. 최종 활성 화면 inventory에서 신규 누락을 발견하면 동일 action 계약에 포함하거나 책임 이슈와 검증 의존성을 명시하고, 조사하지 않은 화면까지 누락 0개라 주장하지 않는다.
구현 순서
- 위 SHA와 최종 source 차이를 확인하고 실제 router별 상태 inventory를 고정한다. legacy 홈은 명시 제외한다. C08 상태 계약과 C01 기본 준비 commit 결과를 먼저 검토한다.
- 실제 제품 consumer를 통한 최소 negative를 만든다: create/edit 초기 await throw, 활성 홈 최초 미완료를 empty로 표시, calendar stream failure, 기본 준비 raw sensitive sentinel.
- 최소 typed read/operation/action state를 기존 Bloc/domain port에 연결한다. 근거 없는 전역 범용 오류 엔진을 추가하지 않는다.
- load/empty/error/stale action UI를 실제 활성 경로에 연결하고 범위·owner·구독·초안 보존과 single-flight를 구현한다.
- validation/protected/conflict/partial result별 action을 기존 workflow/receipt에 연결한다. C01 기본 준비 원자성·결과가 미완료면 해당 선행 작업까지 구현 후 검증한다.
- KO/EN strings와 현재 locale 렌더를 U05와 맞추고 직접 영향 작은 화면/200%/Semantics를 검증한다. settings 왕복·AT 기기 실행 결과를 별도 기록한다.
- 최종 source SHA, 실제 명령/exit code, negative/positive 결과, 호출 횟수·DB 내용 검증, 스크린샷·환경과 미실행 항목을 이 이슈에 추가한다.
실제 실패 증명과 검증 matrix
아래는 실행할 테스트이며 이 문서 작성 중 실행하지 않았다. Mock이 정해진 error state를 출력하는 widget 테스트만으로 실제 예외 경계가 잡혔다고 판정하지 않는다. 실제 Bloc/use-case/제품 consumer에 실패를 주입하고 현재 source의 실패가 수정 후 통과해야 한다. 개인정보 누출 검증에는 실제 개인정보 대신 U09_PRIVATE_SENTINEL, 가짜 SQL/path/password를 사용한다.
| ID | 입력·장애/경쟁 | 필수 기대·증거 |
|---|---|---|
| N01 | 실제 /home에서 nearest 최초 stream 미완료 |
noAppointments 없음, loading 존재. 기존 source before-negative + 수정 후 route test |
| N02 | 활성 MonthCalendar 초기 read throw | 빈 일정 성공 안내/0개 아님, failure+retry. 실제 MonthlySchedulesBloc/route 연결 |
| N03 | calendar 첫 load 및 stream error 각각 | 일반 오류 한 줄/빈 영역 대신 안전 action. read source가 실제 회복하면 목록/empty 정확 전환 |
| N04 | create draft await throw | error 경계 도달, loading 해제, initialDate 보존, retry 1회, back 가능 |
| N05 | edit draft/recurring following segment 조회 throw | 동일 id/scope 유지, 빈 새 일정으로 바뀌지 않음, retry read만 |
| N06 | 기본 준비 save가 sensitive sentinel 포함 예외 throw | 실제 listener/dialog에 원문·SQL·경로 없음, typed 안전 code, 입력 유지 |
| R01 | 성공-empty 오늘/미래/과거 | 기존 create CTA/선택일 인자 유지; 과거 오늘 이동; load error에서 같은 empty CTA로 오인하지 않음 |
| R02 | 같은 범위 성공 후 stream error | stale 표식+기존 자료/선택일/scroll 보존, 성공처럼 오도 없음 |
| R03 | A범위 자료 이후 B범위 load fail | A자료를 B내용으로 표시하지 않음, B retry는 B범위만 |
| R04 | retry 연속 탭 10회 | 실행 중 1회, 구독 중복 없음; 완료 후 명시 retry만 새1회 |
| R05 | retry A pending 중 범위B, A late success/error | B 상태·navigation·scroll 불변, A구독 해제/late emit 거부 |
| R06 | 화면 dispose 또는 owner/store 변경 중 pending | dialog/navigation/새 draft 덮어쓰기 없음, resource close/cancel 확인 |
| R07 | 재시도 중 실제 Future 미완료+시간 경과 | timeout을 완료 취급하여 겹친 write 실행하지 않음, busy 실제 lifetime 유지 |
| R08 | stale row edit/delete/start | authoritative read 성공+동일owner/store일 때만 command. read fail/대상삭제/restore에서는 write 0회 |
| R09 | preparation duration 실패/stream error | 실제0분과 unknown 구분, unhandled error 없음, 안전 읽기 재시도 |
| F01 | 이미 입력한 폼에 read failure/retry late result | 이름/장소/준비/메모/현재step/포커스 보존, U06 dirty 상태 임의clear 없음 |
| F02 | validation field 이동 후 owner 변경 | 올바른 필드 안내, 다른 폼의 페이지/포커스 변경 없음 |
| F03 | protected failure | 유의미한 이유/return, 같은 보호 명령 자동 재시도 없음 |
| F04 | A08 conflict→리뷰 read실패→성공→수락 | draft 유지, 실제 최신값 보여줌, 수락만으로 저장/dirtyclear 없음, 취소는 기존baseline |
| F05 | 확인된 precommit save fault→명시 retry | DB 원래 내용 유지/실제 mutation count, 중복 Schedule·Preparation 없음 |
| F06 | saved+deliveryPending→retry | DB 저장 1회·durable revision 1회, OSfollow-up만 추가, 실제 committed 사실 문구 |
| F07 | 기본 준비 첫 write fault | C01 transaction 결과로 모두 이전 값, 입력 유지, truthful retry |
| F08 | 기본 준비 첫 write 후 둘째 write fault | C01 보강 전 부분commit negative; 보강 후 전체 rollback 또는 명시 typed 부분결과 계약 검증. UI만 수정 통과 금지 |
| F09 | 기본 준비 두 write 성공 후 loadUser fault | committed truth 유지, 후속 read retry만, 두 write 재실행0회 |
| F10 | onboarding 저장 실패/입력 재편집 | 입력·step 보존, 실제 commit 계약에 맞는 action, busy해제·double-submit 방지 |
| E01 | 반복목록 error/empty→retry/create/복귀 | 기존행동 유지, load완료 후 현재screen만 갱신, 중복retry·latecompletion 차단 |
| E02 | freshness 읽기 fail | read retry만, export/restore/reset0회 |
| E03 | backup cancel/invalid/password/stale preview | safe typed 문구, 검증/preview 재수행 전 apply0회, 보존된 DB 동등 |
| E04 | restore/reset committed/uncommitted pending | 현재 receipt/journal의 followup만, 원작업 재적용0회, DB/OS호출·결과검증 |
| E05 | 실제 permission denied/blocked/unsupported와 DBreadfail | 적합 capability에만 설정 CTA; unsupported/DBfail에 불가능 설정 권유 없음 |
| E06 | 설정왕복·resumed 연속 event | 기존coordinator로 상태 재확인, permission prompt/reconcile 폭주 없음. 실제Android/iOS 증거 별도 |
| E07 | Preparation Start failure/부분복구 | A07 latest owner/receipt 사용, 별도Run/자동start없음, 기존회귀유지 |
| E08 | preDI/Recovery startup failure | D01/D02 restricted action, 데이터/키 보존, 정상앱/자동reset 진입없음 |
| V01 | KO/EN 상태별 문구, 화면 locale 변경 | stablecode/args 현재locale 렌더, raw exception 없음, 실행중상태/입력보존 |
| V02 | 작은 화면·200% text·긴 안전 문구 | retry/back/create 버튼 보임/도달가능, overflow없음, 스크롤가능, action경계만직접proof |
| V03 | Semantics와 키보드/AT에 노출되는 action | 명확한 action 이름·disabled/busy상태·focus; 실제TalkBack/VoiceOver는 기기별 별도proof |
| V04 | private sentinel across error surfaces | widget text/semantics/dialog/log-safe DTO에 raw 예외·경로·SQL·password 없음. 원래입력필드 보존과분리 |
완료 기준
- 최종 SHA의 활성 router를 기준으로 모든 위 상태의 위치/원인/action/선행 계약 inventory를 갱신했고 legacy 경로를 구분했다.
- 실제 source before-negative와 실제 Bloc/port/제품 consumer after-proof가 있으며 loading/empty/error/stale가 구분된다.
- 현재 범위 read retry의 single-flight, 범위 전환·dispose·store 교체·late emit 거부, 자원 해제를 증명했다.
- 폼 입력/step/focus를 유지하며 initial read/validation/protected/conflict/precommit/committedpending을 각각 올바른 행동으로 연결했다.
- 기본 준비 순차 write의 C01 선행 보강을 구현·검증했고 두 write 뒤 read failure와 첫 write failure를 다르게 처리한다.
- 저장·복원·초기화·시작의 기존 typed receipt만 재사용하며 후속 retry가 durable write를 중복하지 않는 DB/OS 호출 증거가 있다.
- KO/EN 안전code 렌더, sensitive sentinel 비노출, 직접 영향 작은화면200%/Semantics 검증을 완료했다.
- capability별 설정 행동·복귀 재확인은 실제 지원환경에서 검증하거나 미실행/OPEN으로 명확히 남겼다. CI를 모바일/AT 증거로 대체하지 않았다.
- 적용 source/CI/기기 결과·명령·artifact를 구분하여 이슈에 기록했다. 관련 이슈가 미완료이면 그 의존성을 삭제하거나 완료로 포장하지 않았다.
grill-with-docs 실제 문답 전문
아래는 root와 전담 에이전트가 주고받은 실제 메시지다. 추천안은 질문일 뿐이며 채택/정정된 최종 계약은 앞의 표와 root 답변을 따른다. 조사 중 잘못 인용한 비활성 홈 경로도 원문과 정정을 함께 남긴다.
Q1 — 상태·재시도 범위
에이전트 질문 원문
U09 전담 grill-with-docs 읽고 고정 source 06a238b634a0206f257348db201034fc06eb05c7 확인했습니다. Q1. 오류 후 사용자가 볼 데이터와 재시도 범위를 어떻게 고정할까요? 실제 달력은 load error에서 일반 error 텍스트, 선택일 empty/error에서 빈 SizedBox이고, 홈 주간 일정도 첫 load/stream error에서 빈 SizedBox입니다. 반면 달력 성공 빈 날짜에는 오늘/미래만 일정 추가 CTA가 이미 있습니다(기존 감사의 '빈 상태 전부 미구현' 해석은 수정 필요). 추천: loading / 성공-empty / error-no-data / error-with-last-success 구분, error-with-data는 마지막 성공 데이터를 '최신 상태를 확인하지 못함'으로 유지하되 stale row의 편집·삭제·시작은 새 권위 read/revalidation 통과해야 실행. 명시적 재시도는 현재 선택일/월/주 범위만 한 번 재구독·읽고 날짜/스크롤을 보존, 중복 탭 single-flight, old 요청 결과는 새 범위에 적용하지 않습니다. 성공-empty의 현재·미래 CTA와 과거는 오늘로 이동, 로드실패는 빈 일정으로 단정하거나 자동 reset/신규 profile/로그인·네트워크 안내를 제공하지 않는 것으로 정할까요?
root 답변 원문
Q1 채택합니다. 이미있는성공empty CTA를그대로조사보충에남기고전부없다는단정금지. loading/success-empty/error-no-data/error-with-last-success 구별; stale표시+선택범위/스크롤유지,다른날짜의lastsuccess를현재날짜내용처럼보이면안됨. stale row읽기전용표시는가능하나edit/delete/start등write는현재owner/store+authoritative최신검증이통과해야하며확인불가하면안전오류/재시도,최신확인됐다고추정금지. 현재선택범위명시retry1flight/구독정리, 범위변경시oldcompletion과oldsubscription emit거부, 무한retry/resume폭주없음. 실제pending future를timeout으로취소됐다고간주해겹치는write허용금지(읽기query교체도자원수명관리). 성공empty현재/미래기존create,과거오늘이동을기본으로하며추가와오류retry행동을혼동하지않음. local-only DB오류를네트워크/로그인/빈profile/reset으로치환금지. 실제error원인과사용자에게보여주는안전typed행동구분, rawexception/파일경로/사용자원문로그노출없음.
Q2 — 폼 오류·commit 경계
에이전트 질문 원문
Q2. 폼/편집 오류의 행동을 실패 단계별로 나눌까요? 고정 source에서 A08 저장은 이미 typed conflict/protected/unavailable 및 committed+deliveryPending, owner+mutation+route fence를 갖고 있어 감사의 raw save exception 주장은 일부 해소됐습니다. 그러나 ScheduleFormBloc 생성/편집 load(143–219)는 await 예외를 catch하지 않아 loading 지속 위험, 기본 준비 편집도 initial load 미처리와 save e.toString→dialog(Bloc50,121/UI60)이 남습니다. 기본 준비 저장은 preparation→spareTime→loadUser 순차라 전부 rollback됐다고 말할 수 없습니다. 추천: initial read 실패는 안전문구+동일 create initialDate/edit id·scope 재시도+돌아가기; 이미 편집 입력 있는 read/save failure는 draft/현재 step/focus 보존. validation은 해당 입력으로 이동, protected는 이유+돌아가기(무의미 동일 재저장 없음), conflict는 A08 최신 확인·명시baseline수락, committed+deliveryPending은 알림 후속처리만 retry. 기본 준비 부분저장은 C01 원자성/typedreceipt 보강에 의존, U09가 UI에서 재호출하여 '안 저장됨'으로 포장하지 않음. 반복 관리/백업/시작/복구에 이미있는 retry는 재사용하고 generic 모든실패 다시저장 버튼을 만들지 않는 것으로 정할까요?
root 답변 원문
Q2 채택합니다. A08 typed저장해결은현재근거로보충명시하고과거raw저장예외가그대로라고단정금지. 초기readfailure는동일initialDate/id/scope/owner를보존한read-onlyretry+돌아가기, 초기입력있으면뒤늦은load가초안을덮지않고현재step/focus유지. validation은해당field로안내하되자동페이지이동/포커스가다른owner입력을빼앗지않기. protected원인+안전return,conflict는A08 actualreview/초안유지baseline갱신(dirty자동clear아님),committedpending후속알림만. 기본준비 sequentialwrite결함은source단계별근거를C01의workflow/transaction추가통합항목으로명시(해결된것으로간주금지); U09구현시그port가부분commit을구별하도록최소선행보강이필요하고,없으면genericretry로DB재적용/완전rollback주장금지. 읽어보니실제변경됐는데loadUser실패만난경우와DB첫write실패도분리해야합니다. 기존반복/backup/startup/resetretry는typedcurrentreceipt재사용, 무한retry/자동reset/로그인없음. 추가C01발견은U09명세와최종진행기록에교차링크하고신규네번째엔진말고기존도메인포트로연결하세요.
활성 홈 source 정정
에이전트 보충 원문
Q1 source 정정 보충: router를 추적하니 위 질문에서 인용한 home_screen.dart의 주간 홈/WeeklySchedulesBloc는 활성 /home 경로가 아니었습니다. 실제 go_router.dart:19,121은 HomeScreenTmp→MonthlySchedulesBloc이며, 활성 MonthCalendar는 status를 분기하지 않고 schedules[day]??[] marker를 그립니다. 따라서 U09 활성 홈 결함은 'load 실패가 빈 달력처럼 보임/재시도 없음'으로 정정하고, 옛 주간 홈 빈SizedBox는 비활성 inventory로만 남기겠습니다. 실제 오늘 카드도 ScheduleStatus.initial을 notExists와 함께 null/noAppointments로 보여주므로 첫 read 미완료를 성공empty로 오인하지 않도록 상태 계약 확인이 필요합니다. 원문 질문/답변/이 정정까지 모두 issue에 보존하겠습니다.
root 정정 수락 원문
정정확인·채택합니다. 실제router활성 HomeScreenTmp/MonthlySchedulesBloc/MonthCalendar 기준으로근거와matrix수정하고초기Q1/비활성주간홈언급은실제정정이력으로보존. todaycard initial≠notExists, loading/error/successempty구별은C08 nearest lifecycle계약과함께연결; C08에서최신범위/clock/stream복구를다루므로 U09가별도시간엔진/자동requery루프추가하지않습니다. 최초아직읽지않음은noAppointments라고말하지않고읽는중, 해당read실패는failure로남겨야합니다. 검증은legacyHomeScreen위젯만통과시키지말고실제 /home route 제품노드로연결하세요.
Q3 — 검증·화면 inventory·의존성
에이전트 질문 원문
Q3. 완료 증거와 남은 화면 inventory를 다음 경계로 확정할까요? 추천: 활성 /home 월달력/오늘카드, calendar 선택일, 일정 create/edit 초기로드·검증·save, 기본준비 edit, 반복 관리, onboarding 제출, MyData/복구/reset/알림설정/Preparation Start의 각 loading/empty/readfail/validation/conflict/protected/precommit/postcommit 상태를 최종 구현 SHA로 재목록화합니다. U09는 안전한 문구와 실제 실행 가능한 action 연결, 내부 error→stable code/args 분리 및 직접 회귀만 소유; U03 설정저장, U05 번역, U06 이탈 draft, U07 전체a11y, U08 전체layout, D01/D02 startup/손상DB회복, C01 기본준비 부분commit은 각각 선행/연동 근거를 붙입니다. 설정 action은 실제 permission denied/blocked인 경우에만 기존 capability별 OS 설정 이동+복귀 재확인; 일반 DB/read 오류를 '설정에서 해결'로 오도하지 않습니다. 실제 source에 대한 before-negative(초기load throw, stream error, raw sensitive sentinel)와 after-widget+Bloc/port tests로 재시도 1회·중복탭/범위전환·lateowner 거부·draft유지·DBcommit/OSfollowup 호출수를 증명하고, KO/EN·작은화면200%·Semantics의 이 action 부분을 검증합니다. 모바일 OS설정왕복/스크린리더/전체기기결함재현은 별도 실제 artifact 증거 없으면 미실행/OPEN으로 유지합니다.
에이전트 source 보충 원문
Q3 source 보충: 활성 오늘카드가 쓰는 ScheduleBloc._onSubscriptionRequested(244–261)는 nearest stream .listen에 onError가 없고 enum에도 read error/loading 분리가 없습니다. U09의 initial/empty/error 구분은 C08 포트/상태 보강을 사용해야 하며 별도 nearest 조회 엔진을 만들지 않는 의존성을 명시하겠습니다. 기본준비도 _onFormEditRequested50 미catch, 제출106–108의 두 write 후 loadUser 실패와 첫write실패를 반드시 구분하는 실제negative가 필요합니다.
root 답변 원문
Q3 채택합니다. 실제활성router/최종SHA상태inventory로확정, 미완료loading을empty로표시하는before-negative와rawsensitivesentinel누출검증은실제제품consumer경로필수. action원인별실행가능성명확: DBread오류settings금지,실제권한거부/blocked만capability별기존OS설정+returnrecheck;retry가권한prompt반복폭주로바뀌면안됨. stateID/code/typedargs→KOEN안전render,domain BuildContext/localized예외원문보관없음; 예상불가failure도읽기/쓰기commit확인불가경계보존해무조건retry-save/rollback주장금지. actualBloc/port/DBcallcounts/내용불변·draft·range/staleowner·dispose구독정리증거, 주어진KOEN200%semantics직접범위검증. 플랫폼설정/AT/realcrash별도,지원환경미실행OPEN. C01기본준비부분commit은구체source+최소transaction/typed결과필요로추적하고U09가한UI문구로완료처리하지않음. 실제Q1Q2Q3+활성home정정/모든root보충원문과행동matrix로동결해주세요. 새glossary가아니면추가안함.
C01 추가 통합 책임 확인
root 추가 보충 원문
root가 default_preparation_spare_time_form_bloc.dart L105–121 실제순차 두write+loadUser+e.toString 경로재확인했습니다. C01의미완료통합항목으로확정추적하며 A09 writer정리후 C01 기본준비저장 transaction/typedresult 보강을 다음우선작업에넣겠습니다. U09 issue에는 C01 의존성을기존부분완료로정확히표시, readback만실패했는데DB재저장하는retry금지. 원자적defaultpreparation+spareTime저장과읽기후속실패구별은C01제품포트책임, U09는그결과를안전한메시지/행동으로연결합니다. 이추가실제보충도본문보존부탁합니다.
Activity