feat(F-CMN-002): rubric:read 를 감사 대상으로 넣는다 — 프록시와 한 몸이다 (#609 ② 셋째)

[gitIt-sehyeon]

#609 ② 의 셋째 칸입니다. #610 이 앞쪽 절반(역할·범위)을 냈고 여기가 뒤쪽(감사)입니다.

Important

스택이 셋입니다. #610(정책) ← #612(프록시) ← 이 PR(감사).
머지는 밑에서부터이고, 부모를 --delete-branch 로 머지하면 자식 PR 이 닫힙니다.
각 단계에서 자식 base 를 먼저 돌리거나 브랜치를 남겨 두고 머지해 주세요.

왜 따로 안 내고 여기 붙였나

#612 가 머지되는 순간부터 이 PR 이 들어가기 전까지, 명세가 「감사 대상」이라고 정한 경로가 기록 없이 뜹니다.

AuditInterceptor.java:63
  if (action == null || !policyFile.audited().contains(action)) {
      return;        // ❗조용히 넘긴다
  }

그 구간에 알파 배포가 나가면 채점 정답표를 열어 본 사실이 아무 데도 안 남습니다. 로그 0건은 「아무도 안 봤다」로 읽히고요 — 이 레포가 unreachable 을 따로 세는 이유, #605 가 deniedByRole 을 고치는 이유와 같은 부류입니다.

한 PR 로 합칠 수는 없습니다. rbac_policy.yaml 은 제 파일이고 api/ 는 @hd0rable 님 파일이라, F-CMN-002 의 「파일 단위로 나눈다」가 그것을 막습니다. 그래서 스택입니다 — 두 머지 사이의 틈을 커밋 하나로 줄입니다.

명세가 이미 정해 뒀습니다

docs/functional-spec-v1.2.md:462
| 6 | 루브릭 열람 권한 — SELLER 제외(채점 정답표라 7-4에 걸린다), COMPL·MGR·ADMIN
      읽기 + 감사 대상 | #494 · 프록시(#475)와 동시 | 정세현 |
                ▲▲▲▲▲▲▲

#610 에서 제가 "양쪽 근거가 다 서니 소유자 단독으로 안 정한다" 고 썼던 것이 이미 정해진 것을 다시 여는 것이었습니다(@junseo2323 님이 인용하신 그 행 안에 있었습니다). 여기서 그 결정을 그대로 집행합니다.

@hd0rable 님이 내신 「셋째 축」(루브릭 열람은 사건이 아니라 화면 상호작용이라 호출 빈도가 다르다)은 여전히 값이 있습니다. 다만 그건 "남길까 말까" 가 아니라 "무엇을 남길까" 라, action 을 쪼갤지(rubric:read · rubric:item:read)를 나중에 보면 됩니다 — 그때도 이 줄은 그대로 남고 대상만 좁아집니다. 지금 결정을 미룰 이유는 없다고 봅니다.

❗순서가 강제라는 것을 여기서 다시 실증했습니다

#610 에서는 "넣으면 빨갛다" 를 보였고, 여기서는 프록시가 있으니 통과한다를 보입니다.

#610 시점 (프록시 없음)     everyAuditedActionIsReachable FAILED
지금 (프록시 있음)          BUILD SUCCESSFUL                     ✅

그물

AccessPolicyTest 에 단정을 겁니다. session:simulate 가 같은 자리에 같은 모양으로 서 있습니다(#214 — "S-04 를 띄운 사실이 남아야 한다").

❗감사 대상이다 — 누가 언제 어느 기준을 봤는지가 남는다 (명세 §12.1 6)

변이 역검증: audited 에서 rubric:read 를 빼면 빨개집니다.

검증

server 전체                          BUILD SUCCESSFUL · 832건
변이: audited 에서 빼기                AccessPolicyTest FAILED
everyAuditedActionIsReachable        통과 (프록시가 있으므로)

정책 파일 한 줄과 테스트 하나뿐입니다 — 코드 경로는 안 건드립니다.

Refs #609 · #475 · #494 · #610 · #612

@hd0rable 프록시 위에 바로 얹었습니다. #612 를 머지하실 때 브랜치를 지우지 말아 주세요.
cc @junseo2323 @yoonjiseok

[hd0rable]

승인합니다. 제 「셋째 축」이 결정을 다시 여는 것이었다는 정리가 맞습니다 — 명세 §12.1 6번
행이 "COMPL·MGR·ADMIN 읽기 + 감사 대상" 으로 이미 정했고, 저는 그 행을 인용해 놓고
「양쪽 근거가 다 선다」로 읽었습니다. 제 논점은 "남길까" 가 아니라 "무엇을 남길까" 였고,
그건 action 을 쪼갤 때 다시 보면 됩니다.

재현·역검증

기준선 (이 브랜치 = 정책 + 프록시 + 감사)      ./gradlew test 전체 BUILD SUCCESSFUL

audited 에서 rubric:read 를 뺀다              readingRubricsIsAudited FAILED
프록시를 지우고 audited 만 남긴다               everyAuditedActionIsReachable FAILED
                                             + 「어노테이션이 안 붙은 엔드포인트가 없다」도 빨강
원복                                          초록

둘째가 이 PR 의 스택 순서를 증명합니다. #610 에서는 "넣으면 빨갛다", 여기서는
"프록시가 있으니 통과한다" — 같은 그물의 양방향이고, 그래서 셋으로 가른 것이 임의 분할이
아니라 강제입니다.

두 머지 사이의 틈을 근거로 든 것이 맞습니다

AuditInterceptor:63 이 audited 에 없는 action 을 조용히 넘깁니다. 그래서 #612 가
들어가고 이 PR 이 들어가기 전에 알파 배포가 나가면 채점 정답표를 열어 본 사실이 아무 데도
안 남습니다. 로그 0건이 「아무도 안 봤다」로 읽히는 것이 이 레포가 unreachable 을 따로
세는 이유와 같은 부류라는 지적도 정확합니다.

그 틈을 커밋 하나로 줄이는 것이 스택의 값이고, 한 PR 로 합칠 수 없는 이유(rbac_policy.yaml
은 그쪽 · api/ 는 제 것)도 F-CMN-002 의 규칙 그대로입니다.

그물이 정책 한 줄을 지키는 모양

file.audited() 를 직접 보는 단정이라 정책 파일이 유일한 근거라는 규약과 맞습니다
(Java 상수로 중복 정의하지 않는다 — CLAUDE.md). session:simulate 가 #214 에서 같은 자리에
같은 모양으로 선 것도 확인했습니다.

javadoc 이 "빠지면 AuditInterceptor 가 조용히 넘긴다(:63)" 로 무엇이 깨지는지를 적은 것이
좋습니다 — 단정만 있으면 다음 사람이 「왜 이 목록에 있어야 하나」를 다시 묻습니다.

스택 머지 주의를 본문 머리에 둔 것

--delete-branch 로 부모를 머지하면 자식이 닫힌다는 것 — 제가 #576 때 겪은 자리이고
patrol 스킬(#607)이 함정으로 적어 둔 것과 같습니다. 머지는 제가 밑에서부터 끌겠습니다.

#610 (정책)  →  #612 (프록시 · 제 것)  →  #614 (감사 · 이것)

#610 은 지금 오준서 님 재승인만 남았고(SELLER 는 빠졌습니다), 그게 들어오면 제가 순서대로
base 를 돌려 가며 넣겠습니다.

곁가지 — 제 쪽 후속 하나

audited 가 켜지면 루브릭 열람이 매 조회마다 append-only 기록에 한 줄 쌓습니다. 지금
화면이 없으니 부담이 없는데, #494 화면이 붙은 뒤에 목록·항목을 갈라 볼지(rubric:read ·
rubric:item:read)는 그때 재서 판단하겠습니다 — #606 이 지금 고치는 그 숫자(deniedByRole)가
묻히는지가 판단 기준입니다. 이 PR 을 막을 이유는 아닙니다.