solution_count sort + meili faceting 계약 (contract-first)

[thxforall]

Parent

#825 — [PRD] kiyori 프론트 4-surface 최적화 (map #789)

What to build

Explore 서버 필터/정렬의 백엔드 계약을 philippe와 확정한다: (1) solution_count 정렬(현재 recent/popular/trending만), (2) meilisearch facet distribution 설정+populate(현재 facets 필드는 빈 스텁). 이 슬라이스는 계약·설계만 — FE 실배선은 graduated 슬라이스(별도). Rust/인프라는 philippe.

Acceptance criteria

• solution_count 정렬 + facet distribution의 OpenAPI 계약 shape 합의
• meilisearch faceting 설정 계획 확정(어느 축을 filterable/facet)
• FE가 소비할 facets 응답 계약 문서화(graduated 슬라이스 언블록)

Blocked by

None - can start immediately

[thxforall]

계약 초안 → PR #869 (proposal, philippe 비준 대기)

계약 문서 초안 완료: docs/architecture/explore-facets-sort-contract.md (PR #869, Draft).

Load-bearing 발견: meili posts 인덱스는 이미 solution_count sortable + facet 축 filterable로 구성됨(index_config.rs). solution_count 정렬은 이미 /search에서 동작. facet 갭은 with_facets 배선 + Facets None 하드코딩 제거뿐. → 이 슬라이스는 "faceting 프로젝트"가 아니라 계약 확정 + 작은 배선.

AC 상태:

• (a) 계약 shape 합의 — 제안됨, philippe 비준 대기 ✋
• (b) faceting 설정 확정 — 제안됨, philippe 비준 대기 ✋
• (c) facets 응답 계약 문서화 — ✅ 완료 (PR docs(search): explore facets·sort 백엔드 계약 (#842) #869 Part A)

#851 영향(정확히): 이 계약은 #851의 FE 스캐폴딩을 고정 shape에 대고 착수하게 해줌. 단 #851의 3개 AC는 모두 아직 없는 백엔드(서버 facet/정렬/style_tags 색인)를 요구 → philippe 구현 후에야 통과. "착수 가능"이지 "실행 준비 완료"가 아님.

진짜 결정(philippe): browse(DB) 그리드가 facets/solution_count를 meili 통합으로 얻을지 DB 집계로 얻을지 + facet count = post-filter 확정.

AC-a/b가 사람 비준 필요라 이슈 OPEN 유지. ready-for-agent 제거 = 자율 플릿이 philippe 소유 Rust를 잘못 구현하지 않도록(계약-only 슬라이스). 비준 후 구현은 후속 슬라이스.