[FEAT] 서버 주문표 삭제와 FE↔BE 계약 점검 넷을 반영합니다

[Yena07]

개인 레포에서 코드래빗 리뷰를 마치고 머지한 것 셋을 frontend/ 로 옮깁니다. 백엔드는 건드리지 않았습니다.

개인	내용
#25	서버에 올라간 주문표도 지웁니다 (팀 #79 연결)
#27	계약 점검 1·3·4·10
#28	계약 점검 0·5·6·7

옮긴 것은 코드 파일 8개뿐입니다. .gitignore · .vercelignore · README.md 등도 두 레포가 다르지만, 개인 레포에는 backend/ 사본이 루트에 있어서 생긴 차이라 안 건드렸습니다.

---

① 서버에 올라간 주문표도 지웁니다 (팀 #79 연결)

DELETE /api/v1/users/{userId}/profiles/{profileId} 를 붙였습니다. '이 기기에서 정보 지우기' 가 이제 서버까지 닿습니다.

화면 문구도 둘로 나눠 적습니다 — 주문표는 지워지고, 키오스크에 보낸 승인·거절 기록은 여전히 남습니다. 뭉뚱그려 "다 지워져요" 라고 하면 그게 거짓말이 됩니다.

배포본에서만 나던 구멍

api/bff.ts 가 GET·POST 만 넘겨 주고 있어서 DELETE 는 운영에서 405 가 났습니다. 개발 서버의 프록시는 다 넘겨 줘서 로컬에서는 안 보였습니다.

경로별 메서드 허용 목록을 두고, 메서드 검사를 경로 파싱 뒤로 옮겼습니다.

const 기본허용메서드 = new Set(["GET", "POST"]);
const 메서드별추가허용 = [
  { 메서드: "DELETE", 경로: /^api\/v1\/users\/\d+\/profiles\/[^/]+$/ },
];

src/api/bff-guard.test.ts 를 새로 넣었습니다. api/bff.ts 는 Vercel 서버 함수라 브라우저 테스트 환경에서 import 할 수 없어서, 파일을 글로 읽고 정규식을 뽑아 검사합니다. DELETE 가 프로필 상세 경로 하나에만 열려 있는지, 기본 메서드 목록에 안 섞였는지, userId 자리가 숫자만 받는지를 못 박습니다.

② 재확인 분기가 죽어 있었습니다

RECONFIRMATION_REQUIRED 검사가 INVALID 검사 아래에 있어서 한 번도 닿지 못했습니다.

백엔드는 reconfirmationFields 가 비지 않을 때만 RECONFIRMATION_REQUIRED 를 내고, 그 필드는 contractValidation.errors 에서 만듭니다. 킷이 HARD_CONSTRAINT_UNKNOWN 을 warning 이 아니라 error 로 넣기 때문에, RECONFIRMATION_REQUIRED 이면 valid 는 반드시 false 입니다. 그래서 늘 INVALID 쪽이 먼저 던졌습니다.

결과적으로 알레르기를 모르는 분에게 돌아갈 길 없는 오류(recoverable: false)와 킷 원문이 그대로 나갔습니다.

전  "allergenIds 가 UNKNOWN 입니다. 임의로 추론하지 말고 재확인하거나..."   (되돌릴 수 없음)
후  "저장하신 알레르기 중에 저희가 확인하지 못한 것이 있어요..."            (다시 고를 수 있음)

③ 중단된 실행의 진행 표시가 거짓이었습니다

state 가 aborted 인데 다섯 단계가 전부 '됨' 으로 그려졌습니다. 멈춘 주문을 보고 다 된 줄 알게 됩니다. reachedStep 까지만 done, 그 칸은 failed 로 그립니다.

④ 못 맞춘 조건과 후보별 규칙 판정

unmetConditions 를 버리고 있었습니다. 담기는 담는데 한 축이 어긋난 경우가 여기 오는데, 화면까지 오지 않아서 사용자는 자기 조건이 다 반영된 줄 알고 승인했습니다.

warningsByCandidateId · passesByCandidateId 도 받아 씁니다. 예전에는 이걸 버리고 attributes·supportedOptions 로 같은 판단을 다시 했습니다. 같은 판단을 두 곳에서 하면 언젠가 갈라지고, 다시 하는 쪽은 알 수 없는 것이 있습니다 — WARN 이 없다는 사실만으로는 '일치한다' 를 뜻하지 않습니다. 값이 없거나, NO_PREFERENCE 같은 중립값이거나, 후보가 그 항목을 아예 선언 안 했으면 SKIPPED 라 경고에 아무것도 안 남지만 실제로는 "비교한 적이 없다" 일 뿐입니다.

응답에 판정 필드가 아예 없을 때만 예전 방식으로 물러납니다. 필드는 왔는데 그 후보 항목만 없는 것은 '비교한 축이 하나도 없다' 는 뜻이라 빈 것이 맞는 답입니다.

⑤ 장소 가드

카페 주문표로도 주문 버튼이 눌렸습니다. 백엔드가 다루는 것은 닭강정집뿐이라 serviceType 이 UNKNOWN 이 되고 음료·온도·사이즈·시럽은 축 자체가 없어 전부 NO_PREFERENCE 가 되는데, 킷 스키마가 UNKNOWN 을 허용하는 enum 이라 검증은 통과하고 닭강정이 추천됩니다.

게다가 확인표는 UNKNOWN·NO_PREFERENCE 축을 건너뛰므로 확인 카드가 텅 빈 채로 승인 화면이 떴습니다 — 무엇을 담는지 못 보고 승인하게 됩니다.

막을 때 이유를 말합니다. 버튼만 잠그면 왜 안 되는지 알 수 없습니다.

---

확인

frontend/ 에서 직접 돌렸습니다 — tsc --noEmit 0건 · 테스트 243개 통과 · vite build ok

백엔드에 남은 것

이 PR 과는 별개로 #90(V2 마이그레이션)과 #83(주문표 소유권 확인)이 열려 있습니다. 프론트에서 고칠 수 있는 것이 아니라 이슈로만 올려 두었습니다.

Summary by CodeRabbit

• 새로운 기능

  • 저장된 주문표를 서버에서 개별 또는 일괄 삭제하고, 실패 항목을 개별적으로 다시 시도할 수 있습니다.
  • 기기 정보 삭제 시 현재 기기와 서버의 주문표를 함께 삭제합니다.
  • 주문표 주문 기능이 지원되는 장소에서만 활성화됩니다.

• 개선 사항

  • 주문 옵션 해제 시 불필요한 빈 선택 항목을 제거합니다.
  • 서버 판정을 반영해 추천 결과, 점수 및 재확인 안내를 개선했습니다.
  • 진행 상태와 오류 안내를 더 정확하게 표시합니다.
  • 프로필 동기화 및 삭제 요청의 접근 제어를 강화했습니다.

[coderabbitai]

Warning

Review limit reached

@Yena07, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 13 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 3d87e9c6-9826-4b1f-b83c-26ffa0ded11b

📥 Commits

Reviewing files that changed from the base of the PR and between 8627ba4 and 5eb5230.

📒 Files selected for processing (1)

• frontend/src/app/App.tsx

Walkthrough

BFF가 프로필 단건 삭제를 허용합니다. AccountApi와 앱이 서버 주문표 삭제를 지원합니다. 주문표 저장 검증과 서버 규칙 판정 처리를 강화합니다. 지원 장소별 주문 제어와 개인정보 안내를 갱신합니다.

Changes

프로필 및 주문표 삭제

Layer / File(s)	Summary
BFF 및 AccountApi 삭제 계약 frontend/api/bff.ts, frontend/src/api/account.ts, frontend/src/api/account.test.ts, frontend/src/api/bff-guard.test.ts, frontend/src/api/client.ts	프로필 단건 경로에만 DELETE를 허용합니다. AccountApi.deleteSheet와 목·실서버 구현을 추가했습니다. 빈 selections 배열을 포함한 주문표 저장을 거부합니다.
앱 주문표 및 개인정보 삭제 흐름 frontend/src/app/App.tsx	옵션 해제 시 빈 선택 축을 제거합니다. 지원 장소에서만 주문 버튼을 활성화합니다. 서버 주문표를 삭제하고 실패 항목을 재시도합니다. 개인정보 안내를 서버 삭제 동작에 맞게 갱신했습니다.

서버 규칙 판정 처리

Layer / File(s)	Summary
서버 규칙 판정 처리 frontend/src/api/backend.ts, frontend/src/api/backend.test.ts	후보별 PASS·FAIL·RECONFIRM·SKIPPED 판정을 저장하고 추천 비교에 사용합니다. 판정 필드가 없을 때만 기존 계산으로 대체합니다. 재확인 오류를 일반 무효 오류보다 먼저 처리하고 진행 단계 상한을 적용합니다.

Estimated code review effort: 4 (Complex) | ~45 minutes

Sequence Diagram(s)

sequenceDiagram
  participant App
  participant AccountApi
  participant BFF
  participant Backend
  App->>AccountApi: deleteSheet(userId, profileId)
  AccountApi->>BFF: DELETE 프로필 요청
  BFF->>Backend: 허용된 단건 삭제 요청
  Backend-->>AccountApi: 삭제 결과
  AccountApi-->>App: 완료 또는 오류 표시

Loading

Possibly related PRs

• watTHEBUG/kioBridge#30: AccountApi, BFF 라우팅, App.tsx 흐름을 직접 확장합니다.
• watTHEBUG/kioBridge#58: BFF 프로필 경로와 AccountApi를 함께 수정합니다.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 33.33% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	제목은 서버 주문표 삭제 API 연동과 FE↔BE 계약 검증이라는 주요 변경 사항을 구체적으로 요약합니다.

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/frontend-contract-review

---

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 5

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@frontend/api/bff.ts`:
- Around line 98-122: Update the DELETE handling around 메서드가되나 and the
forwarding flow to derive the caller’s user ID from the authenticated session,
then compare it with the user ID captured from the requested profile path before
forwarding. Reject mismatches and unauthenticated DELETE requests, while
preserving the existing route and method allowlist for authorized matching
requests.

In `@frontend/src/api/backend.ts`:
- Around line 1318-1322: 규칙판정들 저장 로직에서 reconfirmationsByCandidateId도 서버 판정 여부에
포함하고 별도 재확인 상태로 저장하세요. 이후 축맞춤()과 화면 응답이 RECONFIRM 결과를 확인표()의 로컬 추정으로 대체하지 않고 이
서버 상태를 전달하도록 수정해, 승인 전에 재확인 및 미충족 조건이 사용자에게 표시되게 하세요.

In `@frontend/src/app/App.tsx`:
- Around line 1269-1289: Update the conditional notice around showOrder, 고른것,
and 백엔드가아는장소 so place === null displays “장소 유형을 고른 뒤 주문할 수 있어요” instead of the
unsupported-place message. Keep the existing “아직 키오스크와 연결되지 않았어요” 안내 only when a
concrete place was selected and 백엔드가아는장소 returns false.
- Around line 4040-4052: 정보 삭제 흐름에서 현재 sheets만 사용하지 말고, 서버 목록 조회가 완료된 뒤
account.listSheets(userId)의 ID와 현재 sheets의 ID를 합쳐 서버 삭제 대상으로 구성하세요. 목록 조회가 실패하면
서버 삭제 완료로 처리하거나 안내하지 말고 사용자가 재시도할 수 있는 경로를 제공하며, 기존 로컬 데이터 삭제 동작은 유지하세요.
- Around line 3693-3706: Update the individual order-sheet deletion flow,
including its confirmation handler and existing deleteSheet path, so that when
the user is logged in it also calls account.deleteSheet for the removed sheet.
Reuse 서버주문표지우기 or its established error/retry behavior, while preserving local
deletion and allowing the same server-delete path for locally-only sheets.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 902bd5c0-5bc1-4ca6-9061-1fcfce1d7e2c

📥 Commits

Reviewing files that changed from the base of the PR and between 013f266 and 25860f6.

📒 Files selected for processing (8)

• frontend/api/bff.ts
• frontend/src/api/account.test.ts
• frontend/src/api/account.ts
• frontend/src/api/backend.test.ts
• frontend/src/api/backend.ts
• frontend/src/api/bff-guard.test.ts
• frontend/src/api/client.ts
• frontend/src/app/App.tsx

[Yena07]

@coderabbitai review

[coderabbitai]

⚠️ Action not completed

Already reviewed.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[coderabbitai]

Actionable comments posted: 2

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (3)

frontend/src/api/backend.ts (3)

1178-1181: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

모든 재확인 항목을 전달하세요.

reconfirmationFields는 배열인데 첫 번째 message만 KioBridgeError에 넣습니다. 여러 조건이 동시에 재확인을 요구하면 나머지 조건이 사라집니다.

모든 사용자 문구를 합치거나 구조화된 배열로 반환하세요. 사용자가 모든 조건을 확인한 뒤에만 재시도할 수 있어야 합니다.

경로 지침의 “못 맞춘 조건이 있으면 감추지 말고 사용자에게 알려야 합니다”를 적용한 지적입니다.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@frontend/src/api/backend.ts` around lines 1178 - 1181, Update the
RECONFIRMATION_REQUIRED handling around sr.reconfirmationFields and
KioBridgeError so every reconfirmation field message is preserved and presented
to the user, rather than only the first entry. Combine all available messages or
pass them as a structured collection, while retaining the existing fallback when
no messages are provided.

Source: Path instructions

---

1421-1428: 🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift

승인 조건을 이 API 계층에서도 강제하세요.

submit()은 후보 허용 여부, 추천 후보 변경 확인, requiresReconfirmation, 저확신 확인을 검사하지 않고 항상 approved: true를 만듭니다. confirmedAt도 이 함수가 현재 시각으로 생성하므로 실제 사용자 확인을 증명하지 않습니다.

또한 recommend()이 화면에서 제거한 후보가 원본 추천 Map에 남을 수 있습니다. submit()은 이 원본을 다시 승인 요청에 사용합니다. 필터를 거치지 않은 후보나 이용 불가 후보가 승인 요청에 들어갈 수 있습니다.

submit() 직전에 허용 후보, 후보 변경 확인, 저확신 확인, 재확인 확인을 모두 검증하세요. 필터 결과가 없으면 허용하지 마세요. 화면용으로 정제한 추천만 저장하고, 검증 실패 시 /internal/orchestrator/approve를 호출하지 마세요.

경로 지침의 “승인 조건(후보 선택·변경 확인·저확신 확인)을 프론트 가드뿐 아니라 이 계층에서도 다시 검사”를 적용한 지적입니다.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@frontend/src/api/backend.ts` around lines 1421 - 1428, Update the submit()
approval flow to revalidate the selected candidate, recommendation-change
confirmation, low-confidence confirmation, and requiresReconfirmation before
calling /internal/orchestrator/approve; reject when no allowed candidate remains
and preserve the existing confirmed-at/user-confirmation contract instead of
unconditionally generating approval data. Ensure recommend() stores the
filtered, screen-refined recommendation rather than the original 추천 Map, and
prevent the approval request from being sent when any validation fails.

Source: Path instructions

---

1083-1095: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

경고 판정에도 동일한 축 해석기를 사용하세요.

경고 루프는 errorCode만 조회합니다. ruleId fallback을 사용하지 않습니다. errorCode가 없거나 새 값이면 continue로 서버가 보고한 불일치가 사라집니다. 통과 루프에는 이미 ruleId fallback이 있어 두 경로의 동작도 다릅니다.

errorCode와 정규화한 ruleId를 함께 처리하는 공통 해석기를 사용하세요. 해석할 수 없는 경고도 버리지 말고 안전한 미충족 또는 재확인 상태로 전달하세요.

경로 지침의 “못 맞춘 조건이 있으면 감추지 말고 사용자에게 알려야 합니다”를 적용한 지적입니다.

권장 수정 방향

+const 축찾기 = (r: 규칙판정) =>
+  규칙축[r.errorCode ?? ""] ??
+  규칙축[
+    (r.ruleId ?? "")
+      .replace(/^CHICKEN_/, "")
+      .replace(/_PREFERENCE$/, "_MISMATCH")
+  ] ?? null;
+
-const 축 = 규칙축[r.errorCode ?? ""];
+const 축 = 축찾기(r);

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@frontend/src/api/backend.ts` around lines 1083 - 1095, Update the
warning-processing loop alongside the existing pass logic to resolve each result
using both errorCode and the normalized ruleId fallback, preferably through a
shared axis-resolution helper. Do not silently discard warnings when neither
identifier resolves; preserve them as a safe unmet or recheck state so
server-reported mismatches remain visible, while retaining the existing
deduplication and row-generation behavior around 본축, 한줄, and 행.

Source: Path instructions

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@frontend/src/api/backend.ts`:
- Around line 1318-1327: Update the rule-result mapping around 서버판정있음 in
frontend/src/api/backend.ts lines 1318-1327 to persist
reconfirmationsByCandidateId as candidate-level status, and propagate that
status through the screen response and approval guard so unconfirmed candidates
cannot be approved. Extend frontend/src/api/backend.test.ts lines 681-706 to
verify matchedOptions remains empty, reconfirmation status and message are
displayed, and approval is rejected when confirmation is missing.

In `@frontend/src/app/App.tsx`:
- Around line 3725-3735: Update 서버주문표모두지우기 and 서버주문표지우기 so a failed
account.listSheets lookup remains authoritative alongside individual deletion
failures. When the lookup failed, ensure the resulting retry confirmation
invokes 서버주문표모두지우기(userId, 아는것) again rather than retrying only 못지운것, and
prevent the deletion-failure confirmation from overwriting this lookup-failure
state.

---

Outside diff comments:
In `@frontend/src/api/backend.ts`:
- Around line 1178-1181: Update the RECONFIRMATION_REQUIRED handling around
sr.reconfirmationFields and KioBridgeError so every reconfirmation field message
is preserved and presented to the user, rather than only the first entry.
Combine all available messages or pass them as a structured collection, while
retaining the existing fallback when no messages are provided.
- Around line 1421-1428: Update the submit() approval flow to revalidate the
selected candidate, recommendation-change confirmation, low-confidence
confirmation, and requiresReconfirmation before calling
/internal/orchestrator/approve; reject when no allowed candidate remains and
preserve the existing confirmed-at/user-confirmation contract instead of
unconditionally generating approval data. Ensure recommend() stores the
filtered, screen-refined recommendation rather than the original 추천 Map, and
prevent the approval request from being sent when any validation fails.
- Around line 1083-1095: Update the warning-processing loop alongside the
existing pass logic to resolve each result using both errorCode and the
normalized ruleId fallback, preferably through a shared axis-resolution helper.
Do not silently discard warnings when neither identifier resolves; preserve them
as a safe unmet or recheck state so server-reported mismatches remain visible,
while retaining the existing deduplication and row-generation behavior around
본축, 한줄, and 행.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 097fac82-f7d7-4240-b98b-c621b8374ea8

📥 Commits

Reviewing files that changed from the base of the PR and between 25860f6 and 4b31b22.

📒 Files selected for processing (3)

• frontend/src/api/backend.test.ts
• frontend/src/api/backend.ts
• frontend/src/app/App.tsx

[coderabbitai]

🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift

재확인 판정의 저장·표시 계약을 함께 수정하세요.

서버가 재확인을 요구해도 현재 구현은 존재 여부만 기록하고 판정 내용을 버립니다. 테스트도 이 빈 결과를 정상으로 간주합니다.

• frontend/src/api/backend.ts#L1318-L1327: reconfirmationsByCandidateId를 후보별 상태로 저장하고 화면 응답과 승인 가드에 전달하세요.
• frontend/src/api/backend.test.ts#L681-L706: matchedOptions=[] 외에 재확인 상태·문구와 미확인 승인 거부를 검증하세요.

경로 지침의 “못 맞춘 조건이 있으면 감추지 말고 사용자에게 알려야 합니다”를 적용한 지적입니다.

📍 Affects 2 files

• frontend/src/api/backend.ts#L1318-L1327 (this comment)
• frontend/src/api/backend.test.ts#L681-L706

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@frontend/src/api/backend.ts` around lines 1318 - 1327, Update the rule-result
mapping around 서버판정있음 in frontend/src/api/backend.ts lines 1318-1327 to persist
reconfirmationsByCandidateId as candidate-level status, and propagate that
status through the screen response and approval guard so unconfirmed candidates
cannot be approved. Extend frontend/src/api/backend.test.ts lines 681-706 to
verify matchedOptions remains empty, reconfirmation status and message are
displayed, and approval is rejected when confirmation is missing.

Source: Path instructions

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (4)

frontend/src/api/backend.ts (4)

931-933: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

중단 사유에도 금지 표현 필터를 적용하세요.

getEvidence()는 e.stopReason과 서버요약.stopReason을 abort.message로 그대로 전달하고, 화면은 이를 출력합니다. 서버가 "결제수단..." 또는 "주문 완료..."를 보내면 금지 문구가 노출됩니다. 보여도되나를 이 경로에도 적용하세요.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@frontend/src/api/backend.ts` around lines 931 - 933, Apply the existing 보여도되나
forbidden-expression filter to abort messages derived from e.stopReason and
서버요약.stopReason in getEvidence(), before the screen displays them. Ensure
server-provided stop reasons such as payment or order-completion text are
replaced or suppressed according to the established filter behavior.

Source: Path instructions

---

498-516: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

reachedStep을 STEPS 인덱스로 사용하지 마세요. reachedStep은 executedActions.length인 반면 STEPS는 다섯 개의 의미 단계입니다. 현재 변환은 동작 수가 4개 이상이면 실제 중단 위치와 관계없이 마지막 단계만 failed로 표시합니다. 서버가 단계 인덱스 또는 동작별 단계 정보를 제공하도록 계약을 맞추고, 그 값을 단계 표시로 변환하세요.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@frontend/src/api/backend.ts` around lines 498 - 516, Update the aborted-step
mapping around 멈춘칸 and the STEPS status conversion so it does not use
reachedStep as a semantic STEPS index. Use a server-provided stage index or
per-action stage metadata, align the backend contract and frontend conversion to
that value, and preserve done/failed/waiting statuses at the actual stopped
stage.

---

1049-1115: 🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win

미매핑 FAIL 판정을 누락하지 않도록 처리해 주세요.

축맞춤은 규칙축에 없는 errorCode를 조용히 건너뜁니다. 서버가 새 FAIL 규칙을 반환하면 사용자의 불일치 조건이 결과에서 사라집니다. 미매핑 FAIL을 일반 불일치 항목으로 보존하고, 해당 입력을 검증하는 테스트를 추가해 주세요.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@frontend/src/api/backend.ts` around lines 1049 - 1115, Update 축맞춤 to preserve
FAIL entries whose errorCode is not present in 규칙축, representing them as a
generic mismatch instead of skipping them; retain existing axis mapping and
deduplication for known codes. Add a test covering an unmapped FAIL result and
verify it appears in the returned MappedOption output.

Source: Path instructions

---

1334-1343: 🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift

결과 저장 키를 pairingId 기준으로 분리하세요.

후보, 규칙판정들, 추천, 마지막키가 profile.id만 사용합니다. 같은 주문표로 새 연결을 시작하면 이전 비동기 응답이 새 연결의 후보와 정규화 결과를 덮을 수 있습니다. App.tsx의 alive 검사는 화면 반영만 막고 이 저장을 막지 않습니다. 모든 결과를 세션별로 저장하고, 오래된 응답은 버리세요.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@frontend/src/api/backend.ts` around lines 1334 - 1343, Update the
result-storage flow around 후보, 규칙판정들, 추천, and 마지막키 to key entries by the current
pairingId rather than profile.id. Track the active pairing/session and ignore
responses whose pairingId is no longer current before mutating any of these
stores, so stale asynchronous responses cannot overwrite the new connection’s
candidates or normalized results; retain the existing alive check for UI
updates.

Source: Path instructions

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Outside diff comments:
In `@frontend/src/api/backend.ts`:
- Around line 931-933: Apply the existing 보여도되나 forbidden-expression filter to
abort messages derived from e.stopReason and 서버요약.stopReason in getEvidence(),
before the screen displays them. Ensure server-provided stop reasons such as
payment or order-completion text are replaced or suppressed according to the
established filter behavior.
- Around line 498-516: Update the aborted-step mapping around 멈춘칸 and the STEPS
status conversion so it does not use reachedStep as a semantic STEPS index. Use
a server-provided stage index or per-action stage metadata, align the backend
contract and frontend conversion to that value, and preserve done/failed/waiting
statuses at the actual stopped stage.
- Around line 1049-1115: Update 축맞춤 to preserve FAIL entries whose errorCode is
not present in 규칙축, representing them as a generic mismatch instead of skipping
them; retain existing axis mapping and deduplication for known codes. Add a test
covering an unmapped FAIL result and verify it appears in the returned
MappedOption output.
- Around line 1334-1343: Update the result-storage flow around 후보, 규칙판정들, 추천,
and 마지막키 to key entries by the current pairingId rather than profile.id. Track
the active pairing/session and ignore responses whose pairingId is no longer
current before mutating any of these stores, so stale asynchronous responses
cannot overwrite the new connection’s candidates or normalized results; retain
the existing alive check for UI updates.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 2bad13ed-874f-4372-a658-d91c15386441

📥 Commits

Reviewing files that changed from the base of the PR and between 4b31b22 and 8627ba4.

📒 Files selected for processing (1)

• frontend/src/api/backend.ts

[Yena07]

@coderabbitai review

[coderabbitai]

⚠️ Action not completed

Review rate limited.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.