#474 남은 조각 추적 — ①은 있고 ②③은 0건. 열람 프록시부터 (지금 셋 · 데모 뒤 셋)

[yoonjiseok]

#474(설계) · #475(② 서버) · #494(③ 화면)에 흩어진 남은 조각을 한 자리에 모은다. 설계 근거는 저 셋에 있고 여기는 「무엇이 남았고 누구 몫이고 언제냐」만 든다. 조각이 닫히면 여기서 체크한다.

main 23a6b73 기준 실측 (2026-09-11). 결정은 #475 의 ⓐ(승인 = git 커밋 · 서버 stateless)로 9/6 에 났고, 그 뒤 ②③ 구현이 0건이다.

관리자 화면 → 업로드 → 파스 → 추출 → 루브릭 후보 → 사람 승인 → YAML(PR) → CI → 배포
                                     ✅ ①            ❌ ②③            ❌ ②

① ai-service — 윤지석

• POST /internal/rubric/propose 후보 생성 (#476)
• GET /internal/rubrics[/{item_id}] 열람 (#493)
• POST /internal/template/gaps 아무 항목도 안 덮는 문면 (#499)
• ❗**status: draft 가 채점에서 아무 일도 안 한다** — is_draft 가 선언만 있고 호출 0건. 17종 중 7종이 draft 인 채로 confirmed 와 똑같이 채점된다. ⓐ 의 「승인 → draft」 흐름이 이 위에 선다. 갈래는 #475 코멘트(ⓑ: Judgment 에 rubric_status 표시 — 계약 변경이라 @hd0rable 승인). 지금 해도 채점이 안 바뀐다
• #476 응답 모양 ↔ approve 요청 모양 정합 재확인 — 제 9/6 안에 빈칸 셋(productType·name·unlinkedUntil) 있었다. 고친 모양은 #475 코멘트(09-11). #476 쪽은 바꿀 것 없음
• (데모 뒤) 1번 칸 — POST /internal/template/propose 항목 후보. 재현율 분모라 F-EXT-003 과 같이 (#474 코멘트)

② server — 강희진 (#475)

• ❗열람 프록시 — 결정 없이 된다. 지금. GET /products/rubrics[?productType] · /{itemId} → /internal/rubrics. @junseo2323 님이 9/6 에 이것만 먼저 달라고 했고 5일째 답이 없다
• AiServiceClient.proposeRubric(parsedDocument, itemIds?) + POST /products/{id}/rubric/propose 프록시 (읽기 전용 · 상태 안 남김)
• (데모 뒤) POST /products/{id}/rubric/approve — 요청에 u1Requires·status·relatedMisconceptions(비면 unlinked_until) 를 사람이 채우고, 응답은 {yaml, catalogDiff, warnings, appliedOnDeploy: true}. 파일 안 쓴다 · DB 안 쓴다
• ❗catalogDiff 에 risk_item_catalog.yaml 거울 줄이 같이 나가야 RiskItemCatalogMirrorsRubricsTest 가 안 빨개진다 — 사슬을 사람 기억에 안 맡긴다

② 권한·기록 — 정세현

• rbac_policy.yaml 에 rubric:read — #610. ❗제가 적은 「(audited) · 프록시와 같이」가 둘 다 틀렸다(정세현 실측): everyAuditedActionIsReachable 이 «audited 인데 아무도 안 쓰는 action» 을 잡아 audited 는 프록시 뒤여야 하고, audited 여부 자체도 미결이다. 순서: ① permissions(#610) → ② 프록시(강희진) → ③ audited 판단(정세현, ② 위에 스택). ❗그리고 #610 리뷰: SELLER 를 빼야 한다 — README:92 «루브릭은 판매 직원에게 열지 않는다»
• (데모 뒤) rubric:approve — ADMIN·COMPL 범위. 판매 라인(SELLER)은 없다(ADR-001 과 같은 결)
• warnings 문면 — "루브릭이 바뀌면 eval 표본이 낡는다". 응답이 들고 있어야 curl 로 쓰는 사람도 본다

③ web — 오준서 (#494)

• ❗열람 화면 — 열람 프록시가 붙으면 같은 날. 공개 의무(기획서 5절)를 화면이 보이는 자리
• 15-demo-mode.sh 지도에 /api/products/rubrics 줄 — SELLER 가 없어서 ADMIN 으로 (#494 9/7 코멘트)
• (데모 뒤) 후보 검토·승인 화면 — evidence.spans 로 원문에 표시(P6). u1Requires 를 사람이 정하는 칸과 relatedMisconceptions ↔ unlinked_until 배타를 화면이 강제한다(#284 (a) 가 그 자리에서 3주)
• (데모 뒤) 승인 결과 화면 — 「즉시 반영 아님 · PR 로 올린다 · 직접 푸시하면 ai-service 가 안 뜬다」

안전장치 — 이미 있는 것 (새로 만들 것 없음)

_parse / all_rubrics()               깨진 yaml 하나 → 채점 전부 죽는다 → PR 의 CI 가 막는다
RiskItemCatalogMirrorsRubricsTest    거울 어긋남
assert_related_misconceptions_exist  링크가 라이브러리에 없으면 기동 경고
매 배포 --build · app/ 마운트 없음    승인본은 이미지로만 닿는다 (appliedOnDeploy 의 전제)

순서 (제안)

지금        ② 열람 프록시 + rubric:read  →  ③ 열람 화면  →  ① draft 표시
데모 뒤     ② approve  →  ③ 승인 화면  →  ① 템플릿 후보

앞 셋은 S-01(#406)과 무관하고 채점 경로를 안 건드린다 — 9/6 의 「데모 뒤」 근거가 안 걸린다.

관련: #474 · #475 · #494 · #473 · #476 #493 #499 · #367(u1_requires) · #284(unlinked_until) · #409(eval 사슬)

@hd0rable @gitIt-sehyeon @junseo2323

[gitIt-sehyeon]

제 칸의 첫 조각을 냈습니다 — #610. 그런데 재 보니 "열람 프록시와 같이. 지금" 이 「같이」로는 안 됩니다. 셋으로 갈립니다.

1. 나       permissions 에 rubric:read           ← #610. 지금 된다 (server 822건 초록)
2. 강희진    열람 프록시 + @PreAuthorize('rubric:read')
3. 나       audited 에 한 줄                     ← 2 의 브랜치 위에 스택으로 쌓습니다

❗순서가 강제입니다 — 양쪽 다 테스트가 막습니다

permissions 에만 넣는다        server 전체 초록                              ✅
permissions + audited 둘 다    everyAuditedActionIsReachable FAILED         ❗

AccessControlWiringTest 가 「audited 인데 아무 컨트롤러도 안 쓰는 action」 을 잡습니다("감사 로그가 0건인데 그 0건이 「접근이 없었다」로 읽힌다"). 그래서 3번은 2번 뒤입니다.

반대 방향도 있습니다. everyDeclaredActionExistsInPolicy 가 「정책에 없는 action 을 쓰는 컨트롤러」 를 잡으므로 1번이 2번보다 먼저여야 합니다. @hd0rable 님 프록시 PR 이 초록이려면 #610 이 들어가 있어야 합니다.

3번을 2번에 얹어 달라고 하지 않겠습니다 — rbac_policy.yaml 은 제 파일이고 F-CMN-002 는 파일 단위로 갈라 둔 것이 규칙입니다. 프록시 브랜치가 서면 그 위에 바로 쌓습니다.

❗(audited) 에 결정이 하나 남아 있습니다

본문이 rubric:read(audited) 로 적으셨는데, 지금 정책의 선과 대조하면 그렇게 단정되지 않습니다. 전수로 갈라 봤습니다.

audited 인 읽기      aggregate:heatmap:read · aggregate:indicator:read · audit:read
                    · report:read · signal:unfair:read     → 고객 데이터이거나 비공개 정보

audited 아닌 읽기    ops:status:read · product:read · report:summary:read
                    · session:judgment:read · session:read  → 카탈로그 · 운영 상태 · 자기 세션

루브릭은 공개 의무의 대상입니다 — #493 이 든 이유가 "공개 의무를 화면이 보일 수 있게" 이고, 이 이슈 ③ 칸도 "공개 의무(기획서 5절)를 화면이 보이는 자리" 로 적혀 있습니다. 공개해야 하는 것을 조회 기록으로 남기는 것은 위 선과 결이 어긋납니다. 바로 옆 ops:status:read 도 "고객 데이터를 안 읽으므로" 를 근거로 #522 에서 audited 를 뺐습니다.

반대 근거도 섭니다. 판매 라인이 채점 기준을 조회한 사실은 "이렇게 답하게 유도하면 통과한다" 로 이어질 수 있어 7-4 결입니다. signal:unfair:read 가 audited 인 축과 같습니다.

양쪽이 다 서고, 게다가 편의와 한쪽 결론이 같은 방향이라(안 넣으면 지금 낼 수 있다) 제가 단독으로 정하지 않겠습니다. #610 은 그 자리를 비워 두고 두 근거를 주석으로 적었습니다. 3번에서 한 줄로 붙습니다 — 어차피 프록시 뒤라 시간이 있습니다.

@yoonjiseok @hd0rable 어느 쪽으로 보시는지 알려 주시면 3번에 그대로 넣겠습니다.

곁 — 이 작업 중에 나온 별건

--tests '…security.*' 로 돌리다 main 이 단독 실행에서 빨간 것을 봤습니다. #611 로 뗐습니다 — 정책 파일을 만지는 사람이 가장 먼저 칠 명령이라 이 자리에서 유독 자주 밟힙니다. 전체 실행은 초록이라 CI 에서는 안 보입니다.

[junseo2323]

③ web 담당분 현황과, #610 이 여기로 넘긴 audited 판단입니다.

❗먼저 — #610 의 roles 에 SELLER 가 들어 있습니다

변경요청을 걸어 뒀습니다(리뷰). 9/7 에 #494 에서 "문면은 이것으로 확정합니다" 로 닫힌 [COMPL · MGR · ADMIN] 과 다르고, 명세 §12.1 6번 행("SELLER 제외 — 채점 정답표라 7-4에 걸린다")과도 다릅니다.

제 쪽에서 실물로 갈립니다. 알파 개방 모드의 default 계정이 seller-01 이라, SELLER 가 목록에 있으면 프록시가 붙는 날 /api/products/rubrics 가 지도 줄 없이도 seller-01 로 200 입니다 — 시연에서 판매자 계정이 정답표를 여는 화면이 그대로 섭니다.

막고 있는 것은 목록 한 줄이지 순서가 아닙니다. ⓐ(SELLER 빼기)만 반영되면 바로 승인하고, 그러면 ② 프록시가 그 위에 섭니다.

audited — 넣는 쪽입니다

#610 이 "지금 audited 의 선은 「고객 데이터이거나 비공개 정보」다" 로 정리했는데, 그 선은 지금 목록의 설명이지 규칙이 아닙니다. 파일 안에 반례가 둘 적혀 있습니다.

rbac_policy.yaml:234-235
  # 상품 등록·추출은 게이트의 분모를 바꾼다 — 누가 언제 했는지가 남아야 한다 (결정 10.36).
  - product:manage                      ← 고객 데이터가 아니다

rbac_policy.yaml:236-237
  # ❗S-04 를 **띄운 사실**이 남아야 한다 (#76 · 기획 7-2 — "누가 무엇을 봤는지 남는다")
  - session:simulate                    ← 열람 사실 자체가 이유다

루브릭은 채점 기준 자체라 product:manage 가 든 「분모」 축에 더 가깝습니다. 항목을 줄이면 게이트가 느슨해지고, 기준을 보면 무엇을 말해야 하는지를 압니다 — 같은 축의 양면입니다.

그리고 공개 의무와 안 부딪칩니다. 공개 의무가 말하는 것은 "기준이 문서로 존재하고 감사·심사가 볼 수 있다" 이지 "조회를 안 남긴다" 가 아닙니다 — #494 가 SELLER 를 가를 때 쓴 그 구별이 여기도 그대로 섭니다.

실물 근거 하나 더. #494 의 관리자 화면은 한 화면에서 rubric:read 와 product:manage 를 같이 합니다. 한쪽만 audited 면 그 화면의 감사 기록이 반쪽이 되고, 시연에서 그 로그를 보여 줄 때 설명이 안 됩니다.

비용 쪽은 걱정 없습니다 — 열람 프록시는 화면 진입에 한 번이라 session:simulate 가 적어 둔 디바운스 폭주 모양이 아닙니다.

순서는 #610 실측대로 프록시 뒤가 맞습니다(AccessControlWiringTest:194 가 소비자 없는 audited 를 잡습니다). 3번 칸에서 한 줄로.

③ web — 제 칸

열람 화면              ② 프록시 대기. 계약 경로가 openapi 에 서면 같은 날 낸다
15-demo-mode.sh 줄     아래 한 줄 준비됨. 경로 확정되면 바로
(데모 뒤) 승인 화면 둘   그대로 데모 뒤

지도 줄은 #475 의 계약(GET /products/rubrics[?productType] · /{itemId})대로면 $ 로 닫되 하위 한 칸만 엽니다.

    # rubric:read — [COMPL·MGR·ADMIN org]. SELLER 가 없어서 default(seller-01) 로는 403.
    # admin-01 을 싣는 이유는 같은 화면의 product:manage 와 감사 기록의 「누가」를 맞추기 위함.
    ~^/api/products/rubrics(/[^/]+)?$       "Basic $(b64 "$admin")";

9/7 에 적었던 ~^/api/rubrics$ 에서 두 곳이 바뀝니다 — 계약 경로가 /products/ 아래이고, /{itemId} 가 있어서 한 칸을 열어야 합니다. ~^/api/products/rubrics/ 로 넓히지 않습니다(그 파일 주석이 짚어 둔 자리). 바로 위 ~^/api/products/(documents|[^/]+/extract)$ 와는 안 겹칩니다 — 그쪽은 /extract 로 끝나야 매칭됩니다.

@hd0rable ② 프록시는 #610 목록만 정리되면 막힘이 없습니다. @gitIt-sehyeon @yoonjiseok

[yoonjiseok]

① 앞 절반을 냈습니다 — #617

채점을 안 바꾸고 「아무도 모르는 상태」만 없앴습니다. 기동 로그 한 줄 + 목록 못 박기입니다. 뒤 절반이 아래 결정입니다.

17종 중 7종이 draft (변액 10종 중 7종) · ELS 는 전부 confirmed
is_draft 호출 — app/ 안에서 0건 (tools 하나뿐)

❗**#612(열람 중계)가 머지되면 화면이 이 17종을 보여 줍니다 — 변액을 열면 10종 전부가 draft 입니다.** 그 화면이 서기 전에 갈래를 정하는 게 맞습니다.

---

❗계약 변경 요청 — Judgment.rubric_status (@hd0rable 승인 필요)

#475 코멘트에서 제가 ⓑ 를 봤고, 그 뒤로 근거가 하나 늘었습니다. 구체안을 냅니다.

왜 ⓐ 가 아닌가

ⓐ draft 를 채점에서 뺀다   rubrics.get() → RubricNotFound → 그 항목 미측정 → R-00 이 RED
                          ❗「승인했는데 안 돈다」 — appliedOnDeploy 와 다른 종류의 조용함이다
                          승인 화면은 초록인데 게이트만 막힌다. 데모 채점도 7종만큼 바뀐다
ⓑ 판정이 그 사실을 들고 간다  채점 그대로. 화면·교부문서가 「검토 전 기준」을 말한다

구체안

  contracts/judgment.schema.json  properties
+   "rubric_status": {
+     "enum": ["confirmed", "draft"],
+     "description": "이 판정의 근거가 된 루브릭이 검토를 마친 것인가. optional —
+       이 필드가 생기기 전 레코드에는 없다.
+       ❗없으면 confirmed 로 읽지 않는다 — 「검토를 마쳤다」와 「모른다」는 다르다."
+   }

설정은 _pin_rubric_status(judgment, rubric) 로 _pin_prompt_version · _pin_item_id 옆에 붙입니다 — 후처리 맨 앞에서 서버가 박고 모델에게 안 묻습니다(#152 가 prompt_version 을 그렇게 한 이유와 같습니다).

이 자리가 왜 prompt_version·source 와 같은 층인가

스키마가 그 둘에 이미 같은 논거를 적어 뒀습니다.

prompt_version   "confidence 의 정의가 프롬프트 버전마다 다르다 … evidence 는 append-only 라
                 두 정의가 같은 컬럼에 섞이면 감사 시점에 해석할 근거가 없어진다" (#136)
source           "룰이 정한 U3 도 레코드에서 측정된 U3 와 똑같이 생겼다 … 감사 시점에
                 「이 등급을 모델이 잰 것인가」에 답할 수 없다" (#518)
rubric_status    검토 전 기준으로 낸 판정도 레코드에서 확정 기준 판정과 똑같이 생겼다
                 → 감사 시점에 「이 등급의 기준이 검토된 것인가」에 답할 수 없다

셋 다 「판정이 무엇을 근거로 나왔나」이고 값만으로는 복원이 안 됩니다. evidence.rubric_clause 가 인용한 조항이 어느 상태의 기준에서 왔는지가 지금 레코드에 없습니다.

❗evidence 안이 아니라 최상위인 이유

evidence.rubric_clause 를 한정하는 값이라 그 안이 자연스러워 보이는데, evidence 는 P4 의 객체입니다(발화 인용 + 루브릭 조항). 필드를 늘리면 Java Judgment.Evidence 레코드와 「근거가 비면 안 된다」를 재는 자리들이 같이 움직입니다. 최상위 optional 은 위 둘과 모양이 똑같아 대가가 작습니다.

❗없을 때 confirmed 로 읽으면 안 됩니다

source 는 "없으면 MEASURED 로 읽는다" 인데 여기는 반대로 둡니다. 기본값을 confirmed 로 두면 이 필드가 생기기 전 레코드 전부가 「검토된 기준으로 판정했다」로 읽힙니다 — 실제로는 모르는 것이고, 그게 이 필드를 만드는 이유 자체를 지웁니다. unlinked_until 의 「빈 것 ↔ 없는 것」(#284)과 같은 자리입니다.

❗지금 이 계약을 대조하는 자리가 없습니다

제가 ai-service 쪽만 고쳐도 CI 가 안 잡습니다.

judgment.schema.json      additionalProperties 가 없다(= 추가 허용)
test_structured_output_strict.py:102   "Judgment": False   # 계약 — 선택 필드가 있다
ai-service Judgment ↔ 스키마 대조      없다 (확인함)

그래서 제가 조용히 늘리지 않고 여기서 묻습니다. 강희진 님이 #613 리뷰에서 경고 코드셋 두 벌에 그물이 없다고 짚으신 것과 같은 부류입니다 — 그쪽 별건에 이 계약 대조도 같이 보시면 좋겠습니다.

수요자

• @hd0rable — contracts/judgment.schema.json 오너 · Java Judgment 레코드 · 게이트. ❗P1 을 넘지 않도록 이 값이 판정에 직접 들어가지 않게 하는 것이 맞다고 봅니다. 룰이 쓸 거면 gate_rules.yaml 에서 명시적으로 쓰는 쪽입니다
• @gitIt-sehyeon — evidence/ · 교부 문서. 판정 레코드가 append-only 라 이 필드가 없는 채로 쌓인 것은 나중에 복원이 안 됩니다 — 그게 지금 묻는 이유입니다
• @junseo2323 — S-05 화면. #612 의 열람 화면과 같은 사실을 두 자리에서 보이게 됩니다(목록의 status ↔ 판정의 rubric_status)

제 쪽 준비

_pin_rubric_status 는 기존 핀 셋과 같은 모양이라 코드는 작습니다. 승인 주시면 스키마·Java 레코드는 강희진 님이, ai-service 는 제가 내는 것이 CLAUDE.md 규약에 맞다고 봅니다(계약 파일을 제가 직접 안 고칩니다). 반대 근거가 있으면 그것도 좋습니다 — ⓐ 로 가야 할 이유가 있으면 데모 뒤로 미루는 것이 맞고, 그러면 #617 의 못 박기가 그때까지 상태를 지킵니다.

[yoonjiseok]

❗제 ① 코멘트의 숫자를 정정합니다 — 「변액 7종 전부」입니다

정세현이 #617 리뷰에서 잡았습니다. 제가 "17종 중 7종이 draft (변액 10종 중 7종)" 이라고 적었는데 ELS 10 과 변액 7 을 뒤섞었습니다.

ELS                  전체 10종 · draft 0종      ← 데모가 도는 상품
VARIABLE_INSURANCE   전체  7종 · draft 7종      ❗전부
                     ───────────────────
                     전체 17종 · draft 7종

이 차이가 ⓑ 설계에 걸립니다

항목마다 갈린다   → 항목 배지가 맞다. Judgment.rubric_status 가 그 자리를 채운다
상품 전체가 그렇다 → 「이 상품의 채점 기준은 아직 검토 전입니다」가 **상품 단위 문면**일 수 있다

지금은 뒤쪽입니다. #612 가 머지되면 화면에서 변액을 열었을 때 예외 없이 전부 draft 입니다 — 배지를 7개 붙이는 것과 화면 머리에 한 줄을 두는 것은 읽는 사람에게 다른 이야기입니다.

그렇다고 Judgment.rubric_status 가 필요 없어지지는 않습니다. 판정 레코드는 항목 단위이고 교부 문서·감사가 그 단위로 읽습니다 — 화면 문면이 상품 단위여도 레코드에는 항목마다 남아야 「이 판정의 기준이 검토된 것인가」에 답할 수 있습니다(prompt_version·source 와 같은 이유). 다만 화면을 어떻게 그릴지는 @junseo2323 님 쪽에서 달라집니다.

앞 절반(#617)에 반영했습니다

700cc8a — 숫자를 고치고, 그 문장을 검사로 만들었습니다. 주석에만 적으면 이번처럼 낡습니다. _DRAFT_IN_SCORING 집합만으로는 안 잡히는데, 변액 루브릭이 confirmed 로 하나 늘어도 그 집합은 그대로이고 「전부」라는 문장만 조용히 거짓이 되기 때문입니다.

[yoonjiseok]

① 뒤 절반을 draft 로 올렸습니다 — #623

계약 승인 전이라 contracts/judgment.schema.json 은 안 건드렸습니다. 결정을 구체적으로 보시라고 ai-service 쪽 코드를 먼저 냅니다.

schemas.py   Judgment.rubric_status: Literal["confirmed","draft"] | None
scoring.py   _pin_rubric_status — _pin_prompt_version 옆. 모델에게 안 묻는다
tests        새 파일 하나 · 변이 넷 다 잡힘 (ⓐ4 ⓑ4 ⓒ1 ⓓ2)
계약          손 안 댔음 — 초안만 PR 본문에

@hd0rable 님이 #617 리뷰에서 적으신 "필드를 항목마다 두는 것이 맞다 … 계약은 넓게 두고 화면이 뭉쳐 보여 주는 쪽이 순서가 낫다" 를 그대로 구현했습니다. 승인 주시면 계약·Java 를 그쪽에서 내시고 저는 draft 를 풉니다.

이 PR 이 #617 의 못 박기와 안 부딪힙니다

#617 이 "채점 입력이 두 상태에서 글자까지 같다" 를 단정으로 박아 뒀는데, 그건 입력이고 이 PR 은 출력을 바꿉니다. 그 단정은 그대로 초록이고, 관계를 새 테스트 독스트링에 적었습니다.

반대 방향 하나만 확인 부탁드립니다

Judgment 가 LLM 구조화 출력 스키마이기도 해서(complete_json(model_cls=Judgment)) 모델이 이 칸을 채워 보낼 수 있습니다. 핀이 이기는 것은 단정으로 박았지만, 계약에 필드가 생기면 프롬프트에도 그 칸이 보인다는 것은 남습니다. 지금 판단은 "보이든 말든 우리가 덮는다"(prompt_version 과 같은 처리)인데, 그것으로 충분한지 계약 소유자 눈으로 봐 주시면 좋겠습니다.