자율 개선 일일 보고 — 2026-09-10

요약. 2026-09-10에 자율 개선 에이전트가 26개 프로젝트에서 62회차를 돌려 33건을 릴리즈하고 7건은 머지만 했으며 0건은 변경이 없었고 실패는 1건이다. 에이전트 시간 15시간 32분, 추정 비용 $356.91. 릴리즈: kanpic v0.241.0, pii-masker v1.0.19, ptium v1.69.32, releasedock v0.5.14, Clustara v0.9.280, AgentHub v0.241.0, Invenqor v0.2.30, ReSSO v0.9.76….

• 62회차
• 26프로젝트
• 32배포 준비 완료
• 1릴리즈 진행 중
• 7병합 완료
• 13검토 대기
• 3검증 실패
• 0변경 없음
• 6실행 오류
• $356.91비용
• 15시간 32분에이전트 시간

회차

비용·사용량

무엇을 왜 바꿨나 (원장 발췌)

moyro

• 선택: 검색어가 LIKE 패턴으로 해석되던 문제 수정 (가치 4 / 위험 1 / 작업량 M)
• 결과: 성공
• 요약: 사용자·채널·팀·파일·PAT·감사로그 검색이 모두 클라이언트가 보낸 term 을 그대로 LIKE/ILIKE 패턴에 이어붙여, % 는 “전부”, _ 는 “아무 글자 하나”, \ 는 “다음 글자 이스케이프” 로 새어 나갔다 — 맨 % 하나면 볼 수 있는 계정·채널·팀·파일 목록이 통째로 나오고(이메일 포함), kim_lead 검색이 kimxlead 를, @team_notes 가 teamxnotes 를 함께 잡았으며, 반대로 이름에 진짜 % 가 들어간 채널(“50% 할인”)은 이름을 그대로 쳐도 찾을 수 없었다. emojis 는 예전 회차에 strpos 로 피해 갔지만 이 경로들은 대소문자 무시 prefix/contains 매칭이라 strpos 로 바꿀 수 없어 ILIKE 를 유지하고 term 을 이스케이프했다. 12개 call site 가 각자 와일드카드를 손으로 붙이던 것이 누락이 번진 원인이라 store.EscapeLike 와 LikeContains/LikePrefix 로 한 곳에 모았다(PostgreSQL 기본 LIKE 이스케이프가 백슬래시라 ESCAPE 절은 불필요). 파일 검색 핸들러 2곳은 SQL 안에서 '%' || $1 || '%' 로 붙이던 것을 완성된 패턴 바인딩으로 바꿨고, audit.List 는 한 파라미터가 패턴 베이스와 “필터 없음” 센티널을 겸하고 있어 이스케이프된 패턴만 별도 파라미터로 분리했다. 이스케이퍼 표 테스트 2건과 채널 검색·멘션 자동완성·사용자 디렉터리에 대한 PostgreSQL 통합 테스트 3건을 추가했다(각각 와일드카드 해석이었다면 함께 걸렸을 미끼 행을 심어 둔다). 로컬 postgres:16-alpine 컨테이너로 go vet ./..., MOYRO_TEST_POSTGRES_DSN 설정 후 go test -race -p 1 ./...(전 패키지 통과), scripts/check-source-sizes.sh 로 검증했고, 이스케이퍼를 빈 Replacer 로 무력화해 새 테스트 5건이 모두 실제로 실패하는 것(맨 % 가 채널 4개·멤버 3명·계정 3개를 반환)까지 확인했다. 웹 변경이 없어 webapp 빌드는 손대지 않았다.
• 보류 아이디어: (1) webapp/e2e 와 vite.config.ts 가 include: ["src"] 밖이라 어떤 타입체크도 받지 않음 — 별도 tsconfig 와 @types/node 명시가 필요. (2) getPreferenceByName 이 모든 오류를 404로 뭉개 DB 장애를 “설정 없음”으로 위장 — 미머지 브랜치 auto/2026-09-07-0240 이 같은 파일을 손대므로 그 뒤에. (3) post_reminders 에 사용자당 상한이 없어 무한 적재 가능 — 미머지 브랜치 auto/2026-09-08-2109 가 같은 파일을 크게 고침. (4) sidebar.Update 가 사용자가 멤버가 아닌 채널 ID도 카테고리에 기록하도록 허용. (5) postacks/savedposts 통합 테스트 보강 — 명확한 결함은 없고 순수 회귀 방지.

moina

• 선택: 업로드한 WebP 이미지의 실제 픽셀 크기를 저장·응답 (가치 3 / 위험 1 / 작업량 S)
• 결과: 성공
• 요약: imageDimensionsFrom이 image.DecodeConfig만 쓰는데 표준 라이브러리에는 WebP 디코더가 없어, allowlist가 허용하고 웹 앱도 첨부를 받는 image/webp만 언제나 width=0,height=0으로 저장됐습니다(model.Media의 omitempty 때문에 media·Moin 응답에서 크기 필드 자체가 빠졌고, OpenAPI가 mimeType 예시로 쓰는 형식이 바로 WebP였습니다) — API client는 그림이 도착하기 전 자리를 잡을 수 없었습니다. 새 의존성 없이 이미 읽어 둔 sniff 앞부분에서 RIFF 컨테이너의 첫 chunk를 읽는 webpDimensions를 추가해 VP8(lossy, key frame의 sync code 확인 후 14비트 크기), VP8L(서명 뒤 14비트 크기-1), VP8X(flags·reserved 뒤 24비트 canvas 크기-1, 알파·애니메이션) 세 종류를 모두 처리하고, WebP가 아니거나 헤더가 잘린 데이터는 기존처럼 표준 디코더 경로로 넘겨 0,0을 유지합니다. 검증은 libwebp가 만든 실제 WebP 3개(23x17 lossy·31x13 lossless·45x29 알파)로 크기를 대조하고 잘린 헤더·다른 RIFF·PNG 등 7케이스가 거절되는지 확인하는 새 테스트 3개(11케이스) 포함 go test -race ./... 전체 통과, make fmt·make check·go vet·staticcheck 통과(이 환경에 PostgreSQL이 없어 integration test는 skip 상태, frontend 무변경이라 ESLint·vitest 생략).
• 보류 아이디어: updatePost가 DB 오류를 409 not_editable로 보고해 원인을 감춤(가치 2 / 위험 1 / S) · safeFilename이 확장자와 판정한 MIME의 불일치를 그대로 둬 JPEG이 photo.png로 저장·다운로드됨(가치 2 / 위험 2 / S) · Makefile test가 CI와 달리 -race 미사용(가치 2 / 위험 1 / S) · 웹 앱이 API가 주는 미디어 width·height를 쓰지 않아 Flow에서 이미지 로드 중 레이아웃이 밀림(가치 3 / 위험 2 / M)

kanpic

• 선택: 내보낸 CSV·TSV 가 스스로 UTF-8 이라고 밝힌다 (가치 4 / 위험 1 / 작업량 S)
• 결과: 성공
• 요약: 엑셀은 UTF-8 표시(BOM)가 없는 CSV 를 그 컴퓨터의 기본 코드 페이지로 읽는데, 내려받은 표를 여는 길은 대개 두 번 누르는 것이고 그 길에는 인코딩을 물어보는 자리가 없어 한글 칸이 통째로 깨져 보였다 — 관리자 로그(/api/v1/admin/logs.csv)와 AI 기록을 내보내는 자리는 이미 같은 이유로 표시를 붙이고 있었으므로, 정작 한글이 가장 많이 담기는 워크북 내보내기만 빠져 같은 제품이 내주는 두 파일이 엑셀에서 다르게 보이던 셈이다. exportDelimited 가 csv 와 tsv 모두 앞에 표시를 붙이게 하고, 이미 그것을 떼고 있던 parseDelimited 와 같은 utf8BOM 을 쓰게 해 붙이는 자리와 떼는 자리를 한 값으로 묶었다(IMPORTDATA 의 internal/external 도 이미 뗀다). 검증: 새 테스트 TestDelimitedExportMarksItselfAsUTF8(csv·tsv 두 갈래 — 표시가 붙는지와, 되돌려 읽은 첫 칸이 표시를 이고 있지 않은지를 함께 본다)와 표시가 붙으면서 깨진 기존 TestCSVExportEscapesFormulaInjection 수정, gofmt -l, go vet ./..., go build ./..., go test ./...(전체 통과), scripts/check-release-docs.sh, scripts/check-commit-identities.sh. 커밋 1개(b4eaa51). 서버가 내주는 바이트라 웹·문서는 손대지 않았고(문서는 내보내기의 인코딩을 말한 적이 없다) npm 검사도 돌리지 않았다.

• 보류 아이디어: csvNumber 자리(formula.DecimalNumber)가 IMPORTDATA 의 "1,200"·"12%"·통화 기호를 글자로 남긴다 / 서버 formatValue 는 글자 “123” 을 수로 읽고 격자는 글자로 보아 숫자처럼 생긴 글자 값에서 두 곳이 갈린다 / IMPORTDATA 의 CSV 파싱 실패(#VALUE!)도 cache_seconds 만큼 담겨 원격이 파일을 고쳐도 회복이 늦다 / 파이프(|)로 가른 파일을 후보에 넣을지 — 로그·DB 덤프가 흔히 쓰는데 지금은 한 열로 들어온다 / 가져오기가 UTF-16 로 저장한 CSV 를 “CSV must be UTF-8 encoded” 로 거절한다(엑셀의 ‘유니코드 텍스트’ 저장이 그 꼴이고 BOM 으로 알아볼 수 있다) / ? 의 자리 맞추기 빈칸을 그리지 않아 # ??/?? 의 한 자리 분자가 자릿수를 맞추지 못한다

• 릴리즈: v0.241.0 (2026-09-10, run 2026-09-10-000118-kanpic-improve)

pii-masker

• 선택: 재기동이 job 파일 보존 기한을 밀어내던 문제 수정 (가치 3 / 위험 1 / 작업량 S)
• 결과: 성공
• 요약: jobs.Store.load()가 하드 킬로 queued/running 상태로 남은 job을 job_interrupted failed로 바꾸면서 UpdatedAt을 현재 시각으로 올리고 그 변경을 디스크에 쓰지 않아서, 다음 기동 때 다시 디스크의 원래 상태를 읽고 또 시각을 올리는 일이 반복됐습니다. 보존 기간(기본 24시간)이 UpdatedAt 기준이므로, 보존 기간보다 자주 재시작하는 서버에서는 중단된 job의 업로드 원본(=마스킹해 달라고 받은 개인정보 원문)이 영구히 지워지지 않았습니다. 이제 중단 표시는 job이 마지막으로 바뀐 시각을 그대로 유지하고, 그 전환을 persistLocked로 한 번 디스크에 반영해(실패해도 무해) 다음 기동에서 되풀이되지 않게 했습니다. load()가 맵을 직접 채우므로 s.mu를 명시적으로 잡도록 바꿨습니다. 검증은 internal/jobs 테스트 2개(48시간 전 running job이 재로드 후 시각을 유지하고 DeleteExpired(now-24h)로 실제 삭제됨 / 재로드 후 디스크의 job.json이 failed+job_interrupted이고 시각도 그대로)를 추가했고, gofmt -l(무출력)·go vet ./...·go build ./...·go test -count=1 ./...·go test -race -count=3 ./... 전부 통과, 이전 동작(시각 갱신 + 미영속)으로 임시 되돌려 새 테스트 2개가 실제로 실패하는 것까지 확인했습니다. README의 종료 동작 문단에도 보존 기한이 밀리지 않는다는 점을 적었습니다.

• 보류 아이디어: 동기 슬롯 대기열의 메모리 상한(대기 요청이 이미 읽은 업로드 바이트를 보유) / 업스트림 응답 8MB 절단이 decode_failed로 잘못 보고됨(별도 오류 코드 필요) / internal/config의 나머지 순수 함수(normalizeAllowHosts, normalizeEndpointURL, normalizePIILang/Schema, envInt/envNonNegativeInt/envBool) 단위 테스트 / /v1/jobs/{id}/result가 GET만 라우팅되어 HEAD 프로브가 405를 받음 / 업로드 파일명 유니코드 정규화(NFC) 부재로 macOS의 NFD 한글 이름이 그대로 디스크·메타데이터에 기록됨

• 릴리즈: v1.0.19 (2026-09-10, run 2026-09-10-003120-pii-masker-improve)

muni

• 선택: .hwpx 인용문·코드 블록 왕복 (가치 3 / 위험 2 / 작업량 M)
• 결과: 성공
• 요약: 한글에는 인용문도 코드 블록도 없어서 쓰기는 인용을 들여쓴 문단으로, 코드를 고정폭 문단 여러 개로 흘려보내고 blockContext.quote 는 아무도 읽지 않는 죽은 값이었고, 읽는 쪽에는 되살릴 단서가 없었습니다 — 들여쓰고 고정폭으로 그린 문단은 리더에게 그저 문단입니다. .docx 쓰기가 하는 것과 같이 머리(Contents/header.xml)에 스타일 둘을 심고(인용/Quote, 코드/Code) 문단이 번호로 가리키게 했으며, 이름을 무엇으로 읽을지는 hangul.BlockStyle 한 곳에 두어 워드에서 옮겨온 이름(Source Code 따위)도 받습니다. 인용문은 목록처럼 시작도 끝도 표시가 없는 문단의 줄이라 한 블록으로 모으고, 코드 블록은 한 문단 안에 줄바꿈으로 넣습니다 — 줄마다 문단이면 끝을 알릴 것이 없어 나란한 코드 블록 둘이 하나로 돌아옵니다. 목록 항목·제목은 스타일을 받지 않고(항목의 줄이 통째로 인용이 됩니다), 인용이 여백에서 한 칸 물러난 것은 그리는 방법이지 글쓴이의 들여쓰기가 아니므로 읽을 때 덜어냅니다(그러지 않으면 왕복마다 한 칸씩 밀립니다). 검증은 변경 전에 실패하는 것을 확인한 새 테스트 셋(손으로 지은 파일의 인용 묶기·코드 줄바꿈, 왕복)과 gofmt -l·go vet ./...·go test ./... 전체 통과. 덤으로 여덟 회차 내리 손으로 돌린 gofmt·go vet 을 CI 단계로 넣었습니다(YAML 을 파싱해 단계 차례를 확인). 커밋 59cb89f, 7f6ac57.
• 보류 아이디어: .hwpx 머리글 칸의 기본 음영 (2/3/S) — .docx 는 F3F4FA 를 까는데 .hwpx 는 굵게뿐 / .hwpx 코드 블록의 언어가 왕복에서 사라짐 (2/2/S) — mermaid 코드 블록이 도형으로 다시 그려지지 않음. 스타일 이름에 언어를 담을 수 있는지 / 그림의 그린 크기를 markdown 왕복에서도 지키기 (2/2/S) — 붙임말이나 HTML 태그로 남길 수 있는지 / .hwp 표 캡션의 위치(위/아래) 읽기 (2/2/S) — 지금은 언제나 표 뒤에 붙임 / .hwp/.hwpx 표 행 높이 읽기 (2/2/S) — 편집기가 행 높이를 들지 않아 값어치가 낮음

ptium

• 선택: 시트가 한도에 걸렸을 때 잘린 시트 이름을 말하지 않고 슬라이드 수를 시트 수처럼 말하는 문제 (가치 3 / 위험 1 / 작업량 S)
• 결과: 성공
• 요약: internal/docs/workbook.go 의 readWorkbook 이 슬라이드 한도(maximumSlides 30)에 걸리면 “시트가 많아 앞 30개만 가져왔습니다” 한 줄만 남기고 break 했다 — 빠진 시트 이름을 하나도 대지 않고, 30은 시트 수가 아니라 슬라이드 수라서 시트마다 3장씩 차는 통합 문서는 열두 시트 중 열 시트만 읽고도 “앞 30개(시트)를 가져왔다”고 말했다. 이제 한도를 넘긴 뒤에도 시트를 계속 훑어 빠진 이름을 모으고, 숨긴 시트 경고와 같은 말투로 “슬라이드가 많아 시트(…)는 가져오지 않았습니다. 나눠서 올리면 전부 가져옵니다”(docx 경로가 이미 하는 안내)라고 말한다. 이름은 다섯 개까지 대고 나머지는 “외 n개”로 세며(sheetsNamed), 그 목록 함수를 숨긴 시트 경고·오류와도 공유한다. 빈 시트는 애초에 슬라이드가 될 수 없었으므로 trimGrid 로 걸러 이름을 대지 않는다. 검증: sheetlimit_test.go(통합 문서 4가지 — 시트 34개·시트마다 3장씩 12개·이름이 넘치는 40개·한도 뒤의 빈 시트 + 한도에 딱 맞는 문서가 경고하지 않는지 1가지 + sheetsNamed 6가지)를 추가하고 go vet ./... 와 go test -race ./... 22개 패키지 전부 통과. make test 의 웹 단계(tsc/vite)는 이 워크트리에 node_modules 가 없어 실행하지 못했고, 변경은 Go 코드에만 있다. 커밋 bb8efaf. 버전·릴리스 노트는 이번 세션 범위가 아니라 손대지 않았다.

• 보류 아이디어: 분류기가 평범한 공백(“1 200”)을 숫자로 보아 렌더러가 1 로 읽는 오래된 불일치 — amountOf 브랜치(auto/2026-09-09-1131) 머지 뒤에 (3/2/S) · seriesFromRows 가 표의 값을 쉼표로 다시 쪼개 “1,200” 을 1 과 200 두 점으로 읽는 문제 (3/3/M) · 회계 음수를 막대가 math.Abs 로 그려 부호가 사라지는 문제 (3/3/M) · gridOf 가 행의 r 을 보지 않고 trimGrid 이 빈 행을 지워서 출처 행 번호가 어긋나는 문제 — 미머지 브랜치 auto/2026-09-07-0330 머지 뒤에 (3/3/M) · 숨긴 행·열(hidden="1")을 그대로 표에 넣는 문제 (2/2/M)

• 릴리즈: v1.69.32 (2026-09-10, run 2026-09-10-003125-ptium-improve)

relio

• 선택: 금액·확률 급락 규칙을 설정된 기간 안에서만 세기 (가치 3 / 위험 1 / 작업량 M)
• 결과: 성공
• 요약: 보류 아이디어였던 “DealHealth 규칙을 순수 함수로 떼어내기”를 하다가 그 규칙 안에서 실제 버그를 찾았습니다. 시드 데이터는 AMOUNT_DROP 에 {"percent":30,"days":90}, PROBABILITY_DROP 에 {"points":20,"days":90} 로 기간을 선언하고 관리자 콘솔은 그 JSON 을 편집하게 하며 “임계값을 변경하면 화면, API 와 MCP 분석에 즉시 반영됩니다” 라고 적혀 있지만, 두 규칙의 days 를 읽는 코드가 없어 질의가 돌려준 1년치 이력 전부를 훑었습니다(같은 이력을 쓰는 CLOSE_DATE_SLIPPAGE 만 기간을 지켰습니다). 그래서 열 달 전에 금액이 반토막 났다가 그 뒤로 안정된 딜은 오늘도 “금액 급감” 으로 남았고, 콘솔에서 기간을 좁혀도 아무 변화가 없었습니다. 이제 두 규칙이 자기 기간 안의 변경만 세고, 이력 조회 자체도 규칙들이 요구하는 가장 넓은 기간까지 물러나므로(기존 365일이 하한이라 좁아지는 경우는 없음) 1년보다 긴 기간이 조용히 잘리지 않습니다. 기간을 한정할 수 없는 값(0·음수·숫자가 아닌 값)은 규칙을 꺼버리는 대신 시드 기본값으로 물러납니다. 규칙 switch 는 DealHealth 밖으로 나와 (rule, facts) 의 순수 함수 evaluateHealthRule 이 되었고, healthFacts 가 규칙이 읽는 나머지(이력·의사결정자 수·챔피언 수·단계 상한·now·today)를 모읍니다. 검증은 새 테스트 11개(규칙 8종 전부의 발화·침묵 경계, 단계 상한이 기본값을 이기고 0 은 이기지 못함, 앞당긴 날짜는 지연이 아님, 기간 밖 변경 무시와 좁힌 기간 반영, 알 수 없는 규칙 유형, windowDays 폴백 4종, 이력 조회 기간이 가장 넓은 설정을 덮는지)를 옛 구현으로 되돌리면 실제로 실패하는지 확인 — 전체 이력 훑기·365일 고정·폴백 제거로 되돌리자 3건 실패, 리팩터링 회귀 확인용으로 Before(facts.Today)→Before(now) 와 단계 상한 조건을 망가뜨리자 2건 실패 — 한 뒤 go test -race ./..., go vet ./..., gofmt -l, web typecheck·build, check-env-contract.sh, check-static-assets.sh, previous-release-tag-test.sh 전체 통과. 커밋 574c081.
• 보류 아이디어: 네 intelligence 필터의 Cursor 필드는 어떤 질의도 쓰지 않고 어떤 핸들러도 채우지 않는 죽은 코드 — 상위 200건 뒤를 볼 방법이 없음 (가치 3 / 위험 1 / M) · list_activities·get_contracts·list_quotations 등 나머지 MCP 목록 도구는 페이징 자체가 없음 (가치 3 / 위험 2 / M) · DealsAtRisk 는 영업기회 200건 각각에 DealHealth 를 돌려 딜마다 질의 4번을 쳐 최대 800회 왕복 — 이번에 뺀 순수 함수 덕에 팩트를 한 번에 모아 넣는 구조가 가능해짐 (가치 3 / 위험 2 / M) · 로컬 로그인이 꺼져 있을 때 /auth/login 이 403 과 401 을 갈라 돌려주는 두 번째 열거 통로 (가치 3 / 위험 2 / S) · CI 에 gofmt -l 검사 추가 — 지금은 포맷 위반이 CI 를 통과함 (가치 2 / 위험 1 / S)

releasedock

• 선택: 실행 기록 INSERT 실패를 전부 “이미 실행 중”으로 보고하던 문제 수정 (가치 3 / 위험 1 / 작업량 S)
• 결과: 성공
• 요약: createSimpleRun 은 업로드를 대상 디렉터리에 안착시킨 뒤 simple_runs 에 행을 넣는데, 그 Exec 이 어떤 이유로 실패하든 409 simple_run_active + “이 대상에서 이미 실행 중인 작업이 있습니다” 로 답했습니다. 부분 유니크 인덱스 위반(23505)만이 업로더가 실제로 기다리면 풀리는 상황이고, 사용자 행이 사라진 actor 의 외래 키 위반·연결 끊김·요청 취소는 모두 서버 쪽 실패입니다 — 그런데도 같은 문구가 나가고 에러는 아무 데도 기록되지 않아, 폐쇄망 운영자는 실행 목록에 아무것도 없는 대상을 두고 존재하지 않는 실행이 끝나기를 기다리게 됩니다. errors.As 로 *pgconn.PgError 를 꺼내 코드가 23505 일 때만 409 를 유지하는 isUniqueViolation 을 두고(전체 모드 releases.go 의 isSerializationFailure 와 같은 방식), 나머지는 s.log.Error("could not record a simple run", ...) 로 남긴 뒤 500 database_error / “실행 기록을 저장하지 못했습니다” 로 나누었습니다. 두 경로 모두 기존 defer 가 그대로 동작해 스테이징 파일은 지워지고 동시 실행 슬롯도 반납됩니다. 새 테스트 3건을 simple_conflict_test.go 에 추가했는데, 순수 단위 테스트는 23505·래핑된 23505 만 참이고 23503·23514·40001·context.Canceled·일반 오류·nil 은 거짓임을 확인하고, 스키마 격리 통합 테스트 두 건은 실제 핸들러로 멀티파트를 올려 (1) RUNNING 실행이 있으면 409 simple_run_active, (2) users 에 없는 actor 로는 500 database_error 가 나가는지, 그리고 두 경우 모두 대상 디렉터리가 비고 슬롯이 0 이며 실행 행이 남지 않는지 검사합니다. 고치기 전 코드로 되돌려 (2) 가 status = 409 로 실패하는 것도 확인했습니다. 로컬 도커 PostgreSQL 16 으로 TEST_POSTGRES_DSN 을 채워 backend/runner go vet·go test ./...(통합 테스트 포함), npm ci, npm test -- --run(90건), npm run build(tsc -b 포함) 을 모두 통과했고 web/dist 는 커밋 전에 지웠습니다. 사용자에게 보이는 동작 설명이 바뀌지 않아 docs 는 손대지 않았고, VERSION 은 릴리즈 세션의 몫이라 건드리지 않았습니다.
• 보류 아이디어: 전체 모드의 릴리즈 업로드(releases.go)와 프리셋 업로드(presets.go)도 ParseMultipartForm 을 써서 같은 임시 사본이 생깁니다 (가치 3 / 위험 3 / M).
• 보류 아이디어: CI 와 Makefile 에 go vet(또는 golangci-lint) 단계가 없어 정적 검사가 매 세션 수동입니다 (가치 3 / 위험 1 / S).
• 보류 아이디어: 진행 중 실행의 SSE 중복 제거가 줄마다 전체 배열을 훑어 긴 로그에서 O(n²) 이 됩니다 — 마지막 id 비교로 충분합니다 (가치 2 / 위험 1 / S).
• 보류 아이디어: simpleRunLogger.append 가 빈 payload 를 저장하지 않아 스크립트 출력의 빈 줄(문단 구분)이 로그에서 사라집니다 (가치 2 / 위험 1 / S).

• 보류 아이디어: 로그 한도 도달을 알리는 system 행이 system 예산을 차감하지 않아, 예산 회계에서 벗어난 유일한 행입니다 (가치 1 / 위험 1 / S).

• 릴리즈: v0.5.14 (2026-09-10, run 2026-09-10-010116-releasedock-improve)

weekly

• 선택: 완료 숨기기가 상황판에 시키던 거짓말 두 가지 수정 (가치 3 / 위험 1 / 작업량 S)
• 결과: 성공
• 요약: 담당자 보기는 byAssignee(tasks, …) 에 이미 걸러진 목록을 넘기고 doneRatio(lane.tasks) 로 완료율을 냈습니다 — 완료 숨기기 를 켜면 레인에 완료 줄이 하나도 남지 않으므로 모든 사람이 언제나 0/n · 0%, 막대는 0 이었습니다. 끝낸 일을 감췄더니 아무도 아무것도 끝내지 못한 것으로 그려지는 것이고, 벽에 걸린 판이 사람 이름 옆에서 하는 말이라 더 나쁩니다. 같은 필터가 만들던 두 번째 거짓말도 함께 고쳤습니다: 그 기간의 일을 모두 끝내면 목록·담당자 보기가 이 기간에 등록된 업무 일정이 없습니다, 주 보기의 각 칸이 일정 없음 이라고 말했습니다 — 계획이 없는 달과 계획을 다 끝낸 달은 정반대인데 같은 문장이었고, 그것은 v0.294.0 이 “읽지 못한 것을 ‘계획 없음’ 으로 그리지 않는다” 로 막은 바로 그 문장입니다. byAssignee 가 사람의 창 전체(tasks)와 그릴 줄(visible)을 따로 들도록 바꿔 막대와 n/m 은 창 전체로 재고 줄만 걸렀으며, 다 끝낸 사람의 레인은 0% 로 남기지 않고 판에서 내립니다(그것이 완료 숨기기 가 하겠다고 한 일입니다). 비어 있는 이유는 emptyBoardText·emptyDayText 가 모두 완료 와 없습니다 로 구분합니다. 검증: 이전 동작(걸러진 목록으로 레인을 만들고 빈 화면은 늘 ‘없습니다’)을 되돌려 새 시험 2개가 [2] ≠ [1,2]·0% ≠ 50%·'없습니다' 에 '모두 완료' 없음 으로 실패하는 것을 확인 → frontend lint(tsc -b)·build·test 144개가 두 시간대(Asia/Seoul, America/New_York) 모두 통과(새 시험 3개), 실제 DB(WEEKLY_TEST_POSTGRES_DSN)로 go test ./... 전체 통과, go vet ./..., modal-close·paging·openapi·version 검사 통과. Go 는 손대지 않아 guard-check·mutation-check 는 돌리지 않았고(대상 변경 없음), a11y·failstate 검사는 배포와 브라우저가 필요해 이 세션에서 실행하지 못했습니다(CI·수동 점검에서 실행). 사용자 안내서의 상황판 절에 “감추는 것은 줄뿐” 한 줄을 더하고 HTML·PDF 를 다시 생성했습니다. 빌드 산출물(frontend/dist, node_modules)은 .gitignore 에 있어 커밋에 들어가지 않았습니다.
• 보류 아이디어: updateScheduleTask 에 시험이 하나도 없습니다 — 쓰기 넷 중 전체 치환 계약을 가진 하나만 비어 있습니다 (3/1/S) · 상황판 편집이 workItemId 를 담지 않아 업무 링크를 조용히 끊습니다 (2/1/S) · listScheduleTasks 에 상한이 없고 /api/v1/schedule 이 scale-check PATHS 에 없습니다 — 원장의 2026-09-09 2회차 작업이 이 체크아웃(main=v0.294.0)에는 없으니 착수 전에 scheduleRowLimit 존재부터 확인 (3/2/M) · 월 격자의 하루 칸이 담는 줄 수에 상한이 없어 한 날에 몰리면 나머지 칸을 밀어냅니다 (2/2/S) · 월 격자가 이웃 달 며칠까지 조회해 요약 숫자가 ‘이 달’ 보다 큽니다 (2/2/S) · [기각] /api/v1/schedule 이 authz-check 스윕에 빠졌다는 지난 회차 메모는 전제가 틀렸습니다 — authz-check.py 에는 경로 목록이 없고 internal/app/*.go 의 403 거부를 전부 자동으로 훑습니다

Clustara

• 선택: Pod 레벨 securityContext.runAsUser: 0 이 root 로 판정되지 않던 결함 4종 (가치 4 / 위험 1 / 작업량 M)
• 결과: 성공
• 요약: spec.securityContext.runAsUser: 0 를 Pod 레벨에 적고 컨테이너는 아무것도 적지 않는 것이 워크로드를 root 로 돌리는 가장 흔한 형태인데(Pod 값은 덮어쓰지 않은 모든 컨테이너의 기본값), 세 보안 화면이 컨테이너 securityContext 만 읽어 그 워크로드를 root 아님으로 보고했다 — ① SEC-01 classifyPodSecurity 는 runAsUser=0 위반을 아예 만들지 않았고 ② Runtime Security Profile(CLU-OCP-03)의 podSecurityInput 은 Pod 레벨을 읽긴 하지만 무조건 적용해 컨테이너가 실제 UID 로 덮어쓴 Pod 까지 root 로 점수를 매겼으며(반대 방향 오탐), 동시에 containers 만 순회해 privileged init 컨테이너·그 추가 capability·지금 붙어 있는 privileged 디버그(ephemeral) 컨테이너가 위험 설정이 하나도 없는 것으로 채점됐다(같은 Pod 를 정책 엔진과 SEC-01 은 이미 위반으로 적고 있어 제품의 두 부분이 반대 판정) ③ Workspace 건강도의 podHasRuntimeSecurityRisk 는 Pod 레벨을 통째로 무시하고 역시 containers 만 봐서 같은 Pod 를 두고 런타임 보안 화면과 답이 달랐다. 판정을 한 곳으로 모았다 — analyzer.EffectiveRunAsUser 가 컨테이너 → Pod 우선순위를 양방향으로 적용하고(명시적 null 은 미설정), PodRunsAsRoot 가 세 호출자 모두에게 한 번만 답하며, 두 핸들러는 포스처·정책 엔진이 이미 쓰던 analyzer.SecurityRelevantContainers(regular+init+ephemeral)를 순회한다. 검증: 신규 테스트 8개를 고치기 전 코드에 되돌려 붙여 6개가 각 결함을 지목하며 실패함을 확인했고(나머지 2개는 컨테이너가 Pod 의 0 을 덮어쓴 경우와 Pod 의 non-root 를 컨테이너가 덮어쓴 경우를 지키는 오탐 회귀), go build ./...·go vet ./...·go test ./... 전부 통과(20 패키지). 이번 세션 규칙에 따라 버전·changelog·docs 마커는 건드리지 않았다.

• 보류 아이디어: ① .github 에 CI 워크플로 없음 — build/vet/test 게이트 추가 (가치 3 / 위험 1 / S) ② PSS Restricted 검사에 seccompProfile 항목이 없어 RuntimeDefault/Localhost 미설정 Pod 가 Restricted 로 남음 (가치 3 / 위험 2 / S) ③ 취약점 import 가 파싱 못 한 아티팩트를 ‘취약점 0건 완료’ 로 저장 — 400 거절 또는 parse_failed 상태 재검토 (가치 3 / 위험 3 / S) ④ PodSecurityResult 에 cluster_id 가 없어 다중 클러스터 포스처 표가 어느 클러스터인지 말하지 못함 (가치 2 / 위험 1 / S) ⑤ capacity.podRequestGPU 는 nvidia 만, node_monitoring.podGPURequests 는 amd·intel 도 세어 화면마다 GPU 요청량이 다름 (가치 2 / 위험 1 / S)

• 릴리즈: v0.9.280 (2026-09-10, run 2026-09-10-085117-Clustara-improve)

AgentHub

• 선택: 스캔 한도에 잘린 페이로드가 잘렸다는 사실을 어디에도 남기지 않던 문제 수정 (가치 3 / 위험 1 / 작업량 S)
• 결과: 성공 — 커밋 9f84183 (auto/2026-09-10-0851)
• 요약: dlp.Result.Truncated 는 “깨끗한 결과가 완전한 결과로 오해되지 않도록” 존재한다고 주석에 적혀 있는데, 네 경계 전부가 len(result.Findings) == 0 이면 그 자리에서 돌아가므로 스캐너가 유일하게 보증할 수 없는 페이로드 — 한도까지만 읽고 뒷부분은 보지 못한 것 — 이 로그 한 줄도 감사 항목 하나도 남기지 않았습니다. 그것은 끝까지 읽고 아무것도 없었던 페이로드가 남기는 것과 정확히 같아서, 트레일을 읽는 운영자는 둘을 구분할 수 없었고, 큰 도구 결과 비용을 줄이려 MaxBytes 를 낮춘 배포에서는 조용한 쪽이 오히려 일상이 됩니다. 한도는 valueEnd 가 존재하는 이유이기도 한데, 그 함수 주석 자체가 “흔적이라고는 다른 점은 깨끗한 항목에 붙은 truncated 플래그뿐” 인 사고를 설명합니다 — 다른 것이 발견되지 않으면 그 항목은 애초에 쓰이지 않습니다. 이제 잘린 채 깨끗한 스캔은 Incomplete() 이고, 경계는 Reportable() 일 때 기록하며, 트레일은 그것을 audited(아무도 하지 않은 발견을 주장하는 말)가 아니라 자기 이름 unscanned / 일부 미검사 로 파일합니다 — 모델 호출·흐름 실행·결정 기록 전송·리뷰 코멘트, 그리고 발견을 보고하는 것과 같은 방식으로 컨트롤 플레인에 보고하는 Pod 안 도구 게이트웨이까지 네 경계 모두입니다. 이 경로에서 정책은 일부러 묻지 않습니다(판정할 등급이 없고, 데이터 등급 선택자가 빈 규칙은 “모든 등급”이라 한도를 넘긴 프롬프트를 전부 거절하게 됩니다). 아무것도 막지 않고 아무 텍스트도 다시 쓰지 않습니다 — 게이트웨이 호출자는 예전과 같은 nil 을 받습니다. 한도 안에 들어오는 전송은 그대로 조용합니다. 검증: 새 live 테스트 TestAPayloadPastTheScanLimitLeavesATrail 이 Postgres 16 컨테이너에서 프로덕션 생성자(guard.NewModel, Dispatcher.exportDecision)를 그대로 통과해 실제 감사 행을 읽어 오며, 수정 전으로 두 게이트를 되돌리면 dlp.model·dlp.export 두 방향 모두 “흔적이 없다”로 실패하는 것을 확인했습니다. 게이트웨이는 TestAToolPayloadPastTheScanLimitIsReported 이 컨트롤 플레인 대역 서버로 실제 보고(truncated=true, findings 0, blocked=false)를 받고 호출 자체는 손대지 않음을 확인하고, 스캐너·두 게시 경계의 단위 테스트가 “끝까지 읽고 깨끗한 것은 계속 조용하다”를 함께 고정합니다. go build ./..., go vet ./..., go test -race ./cmd/... ./internal/...(DSN 없이/있이 모두), web npm ci+lint+build, release-catalog-images.sh check-versions·validate, kubectl kustomize 통과. internal/dlp·cmd/runtime-proxy 가 런타임 base 이미지 소스라 BASE_VERSION 0.25.0 으로 상향(5곳, 릴리즈 VERSION 은 건드리지 않음).

• 보류 아이디어: 정책 시뮬레이터가 ‘이 규칙이 Pod에서 어떻게 컴파일되는가’를 보여주지 않아 순서 실수를 저장 전에 볼 수 없음 (3/1/M) / 결정 기록 내보내기가 정책에 거절당해도 provenance 화면이 그 건수를 세어 보여주지 않음 (3/2/S) / dlp.tool 보고 엔드포인트만 테스트가 하나도 없어 Pod 가 보낸 값이 감사에 어떻게 들어가는지 아무도 지켜보지 않음 (3/1/M) / 감사 결과(outcome) 값 목록이 서버와 콘솔에 각각 하드코딩돼 드리프트 가드가 없음 (2/1/S)

• 릴리즈: v0.241.0 (2026-09-10, run 2026-09-10-085112-AgentHub-improve)

Vendra

• 선택: 견적을 그 요청이 나간 통화로 매기고, 모든 금액이 어떤 통화인지 말하게 하기 (가치 4 / 위험 2 / 작업량 M)
• 결과: 성공 (commit 2e1abb1)
• 요약: 리스크등급·이메일·공급업체 거래 상태·참가자 상태·연락처 스윕과 같은 기준(철자가 아니라 연산 — 요청 값이 currency 컬럼에 도달)으로 훑었다. 통화 코드를 보는 문은 다섯인데 어느 것도 코드를 보지 않았고 전부 글자 수만 재고 있었으며, 이 상자에 들어가는 잘못된 값은 짧다. 나쁜 쪽은 낙찰이다: recalculateSourcing이 가격을 100*min_amount/total_amount로 제출된 견적 전체에 걸쳐 매기는데 두 통화를 한 척도에 올릴 환율이 애플리케이션 어디에도 없다(spend.currency가 base를 적어 두었지만 읽는 문이 없다). 그래서 68,000,000 KRW 견적들 옆에 선 50,000 USD 견적은 다른 통화의 견적이 아니라 그냥 가장 작은 숫자로 읽혀, 다섯 가중치 중 가장 큰 가격 배점을 통째로 가져가고 비교표 맨 위에 앉았다 — 그리고 그 표는 money()가 저장된 통화와 무관하게 전부 원화로 찍어서 ₩50,000으로 보였다. 무슨 일이 일어났는지 화면 어디에도 없고, 낙찰이 그대로 따라간다. 포털 견적 폼이 KRW/USD/EUR/JPY 넷을 제안하고 있었으므로 이건 API 전용 경로가 아니다. rows.go에 currencyCodes를 riskGrades·supplierStatuses 옆에 두고 다섯 문 전부에 validCurrencyFields/validCurrency를 세웠다(대문자화 — 주소를 소문자로, 웹사이트에 스킴을 붙여 하나의 모양으로 저장하는 것과 같다). 견적의 통화는 요청의 통화로 정하고 다른 코드는 400 currency_mismatch로 무엇으로 내야 하는지 말하며 거절한다. business_objects.currency를 편집이 되쓰는 컬럼에 넣었다 — 생성은 코드를 받는데 그 뒤 어떤 문도 쓰지 않아 잘못 들어간 통화가 정정 요청마다 200을 받고 그대로 남았다. money()는 레코드가 지닌 코드로 찍고 Intl이 모르는 코드에서는 패널을 내리는 대신 숫자와 코드를 같이 답한다. 포털 견적 폼은 넷을 제안하는 대신 그 요청의 통화를 말한다. 검증: docker postgres:16-alpine으로 CI와 동일한 세 DSN을 새 DB에 걸고 go test ./internal/... ./cmd/... 전체 통과, gofmt·go vet 무결, 웹 테스트(17파일 72개)·tsc·eslint·빌드 통과. 가드는 다섯 — 패키지를 파싱해 statement의 컬럼 목록에 currency가 있는 문마다 검사를 요구하는 TestEveryStoredCurrencyIsOneTheApplicationCanPrice, 거절이 상자를 지목하고 저장 모양이 하나임을 고정하는 TestARejectedCurrencyNamesTheBox, 두 문을 API로 걷는 TestABidIsPricedInTheCurrencyTheTenderWasPutOutIn(USD 요청에 KRW 견적 400 → 무기재는 USD로 저장 → 대소문자 → 포털 목록이 통화를 보고)과 TestACurrencyOnABusinessObjectIsOneAndCanBeCorrected, 견적 폼을 실제로 렌더링하는 sourcing-currency.test.tsx 3개. 포털 핸들러의 통화 판단, updateObject의 currency 컬럼, Portal.tsx의 폼과 금액 표시를 각각 되돌리면 해당 가드가 모두 실패하는 것까지 확인했다. 남긴 것 하나: spend_transactions의 sum(amount)는 여전히 통화를 섞어 더한다 — 환율이 놓일 자리를 정하는 것이 먼저라 별건으로 남겼다.
• 보류 아이디어: 초안 축출이 방금 저장한 초안 자신을 버릴 수 있음(putFormDraft의 ORDER BY updated_at DESC 동률) — 고치는 법은 AND draft_key<>$3 (3/1/S) / 공급업체 연간 지출과 지출 리포트가 통화를 섞어 더함 — 환율이 없어 합계 자체가 합계가 아님, 기준통화 정책이나 통화별 집계가 필요 (3/3/M) / 업무 객체 status가 여전히 임의 문자열 — 유형별 어휘가 없어 오타 하나가 집계에서 조용히 빠짐 (3/3/M) / 업무 객체의 data jsonb 블롭에 어떤 검증도 없음 — 폼이 쓰는 키가 API로는 무제한이고 네 키는 결재 라우팅에도 닿음 (3/2/M) / 구매자 화면에는 통화 선택이 없어 모든 업무 객체가 KRW로만 생성됨 (2/1/S)

Invenqor

• 선택: MCP asset_relations 가 관계 목록에 상한을 두지 않아 무한정 큰 응답을 돌려줌 (가치 3 / 위험 1 / 작업량 S)
• 결과: 성공
• 요약: mcpAssetRelations 만 유일하게 LIMIT 이 없어 자산의 활성 관계를 전부 돌려줬다 — process 상관관계가 돈 서버에서 runs_on 자식을 수천 개 가진 host 하나면 도구 호출 한 번의 응답이 모델 context 를 통째로 차지하고, 잘라내는 쪽은 클라이언트였다. 다른 읽기 도구와 같은 limit(기본 50, 최대 100)·offset 을 받고, 한 행을 더 읽어 버리는 lookahead 로 has_more·next_offset 을 사실로 보고하게 했다. 기존 relations 키를 그대로 유지해 응답 호환은 깨지지 않는다. 겸사겸사 가이드의 MCP 도구 표를 mcpTools 스키마와 대조하는 테스트를 추가했고 (openapi.yaml 대 라우터를 대조하는 TestOpenAPIRouteCoverage 와 같은 방식), 그 테스트가 실제로 기존 드리프트인 software_inventory 의 vendor 누락을 잡아내 문서를 함께 고쳤다. 검증: mcp_pagination_test.go 에 두 테스트 추가 — 3개 관계를 limit 3 으로 읽으면 has_more false, limit 2 면 2건·has_more true·next_offset 2 이고 그 offset 으로 나머지 1건이 오며 세 페이지 합이 각 edge 정확히 1회(lookahead 행이 섞이지 않음), 관계 55개에서 limit 미지정이면 50건·has_more true. 헛돌지 않는지 보려고 lookahead 와 비교식을 옛 방식으로 되돌려 두 테스트가 정확히 그 지점에서 실패하는 것을 확인한 뒤 복구했다. 문서 대조 테스트도 표를 고치기 전에 asset_relations·software_inventory 두 드리프트를 차례로 잡는 것을 확인했다. go test ./... 를 SQLite fallback 과 실 PostgreSQL(scripts/test-postgres.sh) 양쪽에서 전 패키지 통과, go vet· go build·gofmt 통과. web·Rust·openapi.yaml(MCP 는 도구별 스키마를 기술하지 않음)은 손대지 않아 npm·cargo·redocly 는 돌리지 않았다. 버전 범프·릴리즈 노트는 하지 않았다.

• 보류 아이디어: Query DSL 실행에 offset 이 없어 상한 500 을 넘는 나머지를 받아낼 방법이 아예 없음 — /api/v1/assets 처럼 offset·total 을 주는 것이 대안 (가치 3 / 위험 2 / M) · Query DSL 에 attributes.<키> 존재/부재 연산자가 없어 >= "" 우회가 필요함 (가치 3 / 위험 2 / M) · MCP asset_search 가 0건일 때 실제 존재하는 type·status 값을 함께 돌려주어 ‘자산 없음’과 ‘필터 값 없음’을 구분하게 함 (가치 3 / 위험 2 / M) · listAgents·설정 목록/이력·자산 상세 루프가 rows.Err() 를 확인하지 않아 부분 결과를 200 으로 돌려줌 — storage 에 테스트용 공개 생성자가 없어 fault injection 불가 (가치 3 / 위험 1 / M) · attributes.* 의 배열·객체 값이 두 저장 모드에서 다른 텍스트로 렌더링됨 — 컨테이너를 가리키는 절을 아예 거절하는 편이 나을 수도 (가치 3 / 위험 2 / S)

• 릴리즈: v0.2.30 (2026-09-10, run 2026-09-10-094107-Invenqor-improve)

ReSSO

• 선택: 로그인 화면이 이쪽 장애를 “로그인 요청이 만료됐다”로 답하던 문제 수정 (가치 3 / 위험 1 / 작업량 S)
• 결과: 성공 (커밋 9529746)
• 요약: RP에서 넘어온 로그인 화면은 폼을 그리기 전에 GET /api/v1/auth/challenge/{token}으로 park된 인가 요청을 먼저 읽는데, 그 읽기의 모든 실패에 한 문장으로 답했다 — “로그인 요청이 만료되었습니다. 연결한 서비스에서 다시 시작하세요.” 그 답이 맞는 경우는 하나뿐이다. 백엔드는 소진·만료·발급된 적 없는 request token에 404를 답하고(writeStoreError), 그것만이 토큰에 관한 사실이며 다시 시작하는 것이 유일한 출구다. 저장소가 답하지 않으면 500이고, 페이지가 재시작 중에 fetch하면 api.ts가 status 0으로 만드는데, 그 둘은 이쪽 문제이고 사람이 들고 있는 요청은 소진되지 않은 채 그대로 남아 있다. 그래서 화면이 가진 그 한 문장은 설명이 아니라 지시였고, 되는 쪽에서 사람을 떼어놓았다: RP로 돌아가 새 request token을 받고 여기 도착해 같은 장애를 다시 만난다. 게다가 그 Alert이 이 화면의 마지막 말이었다 — 누를 것이 없고 challenge.isError가 폼을 계속 막으므로, 장애가 걷힌 뒤에도 화면은 글자 그대로 같아 보였다. 근거는 한 디렉터리 옆에 이미 있었다: 콘솔의 ErrorAlert(components/Feedback.tsx)는 status 0·429·5xx에만 재시도를 내주고 나머지에는 내주지 않으며, 각 상태에 무엇을 할지까지 적어 준다. 로그인 안 한 사람이 보는 유일한 화면만 그 구분을 버리고 있었다. 이제 404만 옛 문구를 유지하고, 나머지는 “요청은 그대로 남아 있으니 연결한 서비스에서 다시 시작하지 말고 잠시 후 다시 시도하세요” + 같은 challenge를 다시 부르는 다시 시도 버튼 + Trace ID다. 백엔드는 손대지 않았다 — 이 구분은 writeStoreError가 이미 하고 있었고, login의 400 expired_request가 저장소 장애를 함께 뭉개는 건은 미병합 브랜치와 겹치므로 그대로 두었다. 검증: 새 테스트 둘 — 소진된 토큰(404)은 여전히 RP로 돌려보내고 재시도 버튼을 내주지 않는 것, 500은 다른 문구와 Trace ID를 보이고 만료 문구를 보이지 않으며 재시도 뒤 Client 안내가 뜨고 폼이 다시 쓸 수 있게 되는 것. 두 번째가 수정 전 페이지에서 실제로 실패함을 확인했다(findByText(/로그인 요청을 확인하지 못했습니다/) 타임아웃). make test 전체 통과(exit 0) — go test -race ./... 전 패키지 ok(httpserver 89s / store 82s), 연동 테스트 SKIP 0건, go vet, npm run test(22파일/106테스트, 디스크 파일 수와 일치), npm run build. make lint도 통과(golangci-lint 0 issues, govulncheck 0, eslint --max-warnings 0). 빌드가 만든 webui/dist/index.html 변경은 되돌렸다. docs/operations.md에 두 문구를 원인·사용자가 할 일로 나눠 읽는 표와 “두 번째 문구가 보고되면 사용자를 RP로 돌려보내지 마세요”를 적었다.

• 보류 아이디어: oidcLogout이 hint의 sub를 쿠키 세션과 대조하지 않아 다른 사람의 ID Token으로도 지금 로그인한 사람이 로그아웃된다(가치 2/위험 2/M) / id_token_hint의 aud를 요청한 Client와 대조하지 않아 같은 Realm의 다른 Client에 발급된 ID Token도 hint로 통과한다(가치 2/위험 2/M) / 로그인 화면이 account_mismatch(403)를 실패 카운터에 세어, 로그인은 성공했는데 “반복 실패하면 계정이 잠긴다”는 안내를 띄운다 — 서버는 그 직전에 실패 횟수를 초기화했다(가치 2/위험 1/S, 새 아이디어) / 로그인 화면이 account_mismatch를 일반 오류로만 보여줘 “지정된 계정으로 다시 로그인하면 이어진다”는 사실이 드러나지 않는다(가치 2/위험 1/S) / UserInfo POST에서 form-encoded access_token 수용, RFC 6750 §2.2(가치 2/위험 1/S)

• 릴리즈: v0.9.76 (2026-09-10, run 2026-09-10-094110-ReSSO-improve)

aiportal-front-admin

• 선택: 세션 만료를 라우트 이동 없이 즉시 복구 — 잃어버린 커밋 e425b54 복구 (가치 4 / 위험 2 / 작업량 M)
• 결과: 성공
• 요약: git branch --no-merged main으로 확인한 대로 원장에 ‘성공’으로 적힌 e425b54가 브랜치 auto/2026-09-06-0140에만 남고 main에 없어, setSessionExpiredHandler()와 auth/guard.ts가 지금 코드에 없었다(src/auth에 session.ts·ssoRedirect.ts·storage.ts뿐, router.beforeEach도 e425b54 이전 형태 그대로). 그래서 세션 만료 응답은 캐시된 관리자 세션을 버리기만 하고 다시 확인하는 주체는 router guard뿐이라, 한 화면에 머무르며 검색·페이지 이동·자동 갱신만 하는 사용자는 라우트를 옮기기 전까지 모든 조회가 실패하는 화면에 갇혔다. 지금 코드 기준으로 재검토한 뒤(현재 router.ts·session.ts가 e425b54의 base와 동일해 cherry-pick이 충돌 없이 적용됐고, ARCHITECTURE.md는 그 뒤 추가된 절들과 자동 병합됐다) 복구했다 — session.ts가 캐시를 버린 직후 만료 handler를 부르고, guard 본문을 새 auth/guard.ts의 resolveAdminAccess(force)(allow/redirected/denied)로 옮겨 router guard와 만료 복구가 같은 판단과 같은 SSO 왕복 제한을 공유하며, /sso/ssologin 자체가 만료 응답을 받는 재귀는 state.checking으로 걸러낸다. 여기에 더해, 이 변경이 두 번이나 조용히 사라져도 아무도 알아채지 못한 이유인 router.ts 배선(만료 handler 등록과 세 판단 처리)에 테스트가 전혀 없던 공백을 src/app/router.test.ts 8개로 덮었다(guard 세 갈래 + public 라우트, 만료 복구의 강제 재확인·화면 유지·access-denied 이동·SSO 이동 중 덧씌우지 않음). 검증은 npm run build(typecheck + vitest 142개 통과, 기존 124개 + 복구 10개 + 신규 8개 → vite build → runtime-config 검증 → offline 검사 → integrity manifest 19개) 전체 통과, 그리고 만료 알림 호출·재귀 차단 가드·force 전달을 각각 되돌리고 router 배선을 네 가지로 변형해(handler 등록 제거, redirected를 access-denied로 처리, 복구 실패 시 이동 안 함, 복구가 캐시 세션 사용) 해당 테스트가 정확히 실패하는지 모두 직접 확인했다. 커밋 c1a4d7b.
• 보류 아이디어: monitoringParser.toPod이 kubectl 스타일 restarts(“3 (5d ago)”)에서 NaN을 표에 노출 (2/1/S) · 결과 0건인 탭을 누를 때마다 ContentAccessView·CatalogView·DirectoryView가 같은 조회를 되풀이 (2/1/S) · PolicyCenterView·AdvancedPolicyView·OverviewView가 createRequestGuard 없이 조회해 늦게 온 이전 응답이 최신 결과를 덮어씀 (2/1/S) · AdvancedPolicyView가 저장할 때마다 load()로 패널 전체를 skeleton으로 되돌림 (2/1/S) · 다른 탭에서 로그아웃해도(storage 이벤트) 이 탭은 라우트를 옮길 때까지 복구하지 않음 — 이번에 만든 만료 handler를 재사용하면 되는 후속 (2/2/S) · AdvancedPolicyView가 snapshot.extensions를 v-model로 직접 변형 (2/2/S) · 루트 앱의 crypto-js local tarball 의존성 제거로 clean install 복구 (4/4/M)

aiportal-front

• 선택: 대화저장 상세(ChatStorageDetail)의 기본앱 비동기 처리 오류 및 봇 식별자 파싱 공용화 (가치 3 / 위험 2 / 작업량 S)
• 결과: 성공
• 요약: src/views/ChatStorage/ChatStorageDetail.vue 가 async 함수 readDefaultApp 을 computed(() => getDefaultBot()) 로 감싸 Promise 를 담고 있어, pickBotIds(Promise) 가 항상 빈 식별자를 돌려주고 appId/prjId 의 기본앱 폴백이 죽어 있던 문제를 고쳤다 — 일반챗봇 히스토리(라우트에 appId 쿼리가 없는 진입)에서 pInf.chat.getHistorySession(대화 불러오기)과 inf.chat.feedbackAnswer(피드백 저장)가 app_id/project_id 를 빈 문자열로 보내고, isGeneralChat 이 영원히 false 라 헤더가 항상 “전문가 AI와 대화중” 으로 표시됐다. defaultBot 을 ref 로 바꾸고 initByRoute 가 세션 조회 전에 ensureDefaultBot() 으로 선로딩하도록 했다(readDefaultApp 은 캐시·inflight 합치기가 있어 추가 호출이 생기지 않는다). 함께 Chat/Main·Chat/Index·ChatStorageDetail 에 각각 복사돼 있던 pickBotIds 를 appDefaultStorage.pickBotIds 로 합쳐(app_id/appId/appID·project_id/prj_id/prjId 표기 모두 처리, 비객체·Promise 방어) Main.vue 의 app_id 단일 표기 사본을 제거했다. 검증은 npm test(총 353건 통과, 신규 6건)와 npm run build:dev(빌드 성공, dist 는 커밋 전 삭제)로 수행했다. 다만 이 저장소에는 컴포넌트 테스트 환경이 없어 .vue 수정 자체는 순수 헬퍼 테스트와 코드 리뷰로만 확인했다.
• 보류 아이디어: mitt 이 package.json 직접 의존성에 없어 전이 의존성에 기대는 문제 (가치 3 / 위험 1 / S) · Header.vue 가 OCR 사용 여부와 무관하게 마운트 즉시 3초 폴링을 시작하는 문제 (가치 3 / 위험 3 / M) · globalLoading 이 참조 카운트 없이 boolean 이라 병렬 요청 중 하나만 끝나도 스피너가 사라지는 문제 (가치 3 / 위험 3 / S) · serviceCode 리터럴 표기 불일치(myNoteBook/MyNotebook/multiModal) 상수화 (가치 3 / 위험 2 / S) · 빌드 산출물 단일 청크 6.2MB 코드 스플리팅(manualChunks) (가치 3 / 위험 3 / M)

ai-admin

• 선택: 대시보드가 조회 실패를 “승인 대기 0건”·”공급자 없음”으로 감추던 문제 수정 (main 재착수) (가치 3 / 위험 1 / 작업량 S)
• 결과: 성공
• 요약: 보류 목록 1번의 재착수 전제였던 “df278de가 왜 병합되지 않았는지”를 먼저 확인했다 — 그 commit이 담긴 auto/2026-09-06-2320은 origin에 아예 push되지 않았고(원격 branch 목록에 없음) git merge-base --is-ancestor df278de main도 NO다. 즉 반려가 아니라 단순 미push였고, 버그는 main에 그대로 남아 있었다: dashboard는 _ = s.db.Pool.QueryRow(...).Scan(&pending)로 승인 대기 건수 조회 오류를 버리고 0을 내려보냈고, dashboardProviders는 조회 실패를 빈 목록으로, scan 실패 행을 건너뛴 짧은 목록으로 반환해 화면의 “등록된 AI 공급자가 없습니다”와 구별되지 않았다. 두 값은 레거시 스키마가 아니라 ai_admin 자기 테이블에서 오므로 degradation으로 볼 이유가 없어, 조회가 실패하면 500 dashboard_unavailable 오류 봉투를 반환하고(DashboardPage.tsx:60이 이미 ErrorState+재시도를 표시한다) 공급자 목록은 v1.2.9의 공통 collectRows 경로를 쓰도록 했다. 레거시 스키마 기반 지표(metrics[].available)의 degradation 계약은 그대로 두었다. 검증은 통과 확인에 그치지 않고, 공급자 상태 매핑·scan 실패 시 부분 목록 없음·연결 불가 pool을 향한 500 응답을 테스트로 덮은 뒤 dashboard 핸들러만 수정 전 형태로 되돌려 TestDashboardReportsApplicationQueryFailure가 실제로 200과 "pendingApprovals":0, "providerHealth":null로 실패하는 것을 확인하고 되돌렸다. Docker로 PostgreSQL 16을 띄워 TEST_POSTGRES_DSN을 걸고 go test -race -count=1 ./...(통합 테스트 포함, internal/server 47s)·gofmt -l·go vet ./...·go build ./...·scripts/verify-version.sh·npm ci && npm test(64개)·npm run build를 모두 통과시켰다. 이번 세션 규칙대로 VERSION·CHANGELOG·릴리즈 메타데이터는 건드리지 않았고(df278de에 있던 버전 bump는 의도적으로 제외했다) docs/api.md에만 대시보드 실패 계약을 명시했으며, 커밋 전 git status로 빌드 산출물이 섞이지 않았음을 확인했다(변경 4개).

• 보류 아이디어: loadGrants가 map 순회로 roles·permissions 순서를 무작위화해 /api/v1/auth/me 응답 순서가 요청마다 뒤바뀜 — 지금 코드(auth.go:250-256)에서 재확인 (가치 2 / 위험 1 / S) · updatePreferences가 locale(varchar 20)·timezone(varchar 80)에 길이 검증 없이 upsert해 긴 값이 400 대신 500이 되고 같은 요청의 다른 설정 변경도 함께 사라짐 (가치 2 / 위험 1 / S) · listUsers의 q에만 200자 상한이 없어(감사·레거시·MCP는 모두 있음) 매우 긴 검색어가 세 컬럼 ILIKE 스캔으로 들어감 (가치 2 / 위험 1 / S) · safeCSVCell이 value[0] 한 byte에서 "=+-@"만 검사해 OWASP가 함께 권고하는 tab(0x09)·CR(0x0D) 선행 문자를 중화하지 않음 (가치 2 / 위험 1 / S) · 새 아이디어: aiModels·aiCatalog가 available_models의 JSON 파싱 실패를 _ = json.Unmarshal로 무시해 모델 목록이 기본 모델 하나로 조용히 줄어듦 (가치 2 / 위험 1 / S) · 새 아이디어: dashboardProviders의 LIMIT 10이 목록이 잘렸음을 알리지 않아 11개 이상 등록 시 일부 공급자가 미등록처럼 보임 (가치 2 / 위험 1 / S)

• 릴리즈: v1.2.17 (2026-09-10, run 2026-09-10-111300-ai-admin-improve)

aiportal-py

• 선택: 백그라운드 루프의 마지막 성공 시각(heartbeat)을 /health 로 노출 (감사 A-112) (가치 3 / 위험 2 / 작업량 S)
• 결과: 성공
• 요약: A-003 으로 task 생존 여부는 /health 에 드러났지만, 세 무한 루프는 모두 주기 안의 예외를 잡고 다음 주기로 넘어가므로 “살아 있으면서 매 주기 실패” 하는 상태가 여전히 healthy 로 보였다(token_store.fetch_external_token 은 실패를 None 으로 삼키고, auto_refresh_question 은 수집이 비면 기존 캐시를 유지한 채 계속 돌며, feedback_batch_loop 도 주기 예외를 로그만 남긴다 — policy token 이 한 번도 발급되지 않은 경우만 checks.m2m_token 으로 드러났고, 발급 후 갱신이 계속 실패하는 경우는 보이지 않았다). util/task_supervisor.py 에 heartbeat(name) 과 register(..., max_silence=N) 을 추가해, 마지막 성공 이후 N 초가 지난 task 를 stale 로 만들고 stale() 로 조회하게 했다 — 살아 있는 상태이므로 중단(stopped())과 분리해 /health 가 “중단된 task” 와 “지연된 task” 를 나눠 알리고, 전이 시점에만 로깅하는 기존 폴링 규칙은 그대로 쓴다. 경과는 시스템 시각 변경에 흔들리지 않도록 monotonic 시계로 재고(테스트 주입 가능), 첫 성공 전에는 등록 시각을 기준선으로 삼아 기동 후 한 번도 성공하지 못한 경우도 잡는다. 허용 간격을 주지 않은 task 의 응답 형태는 그대로다. heartbeat 는 성공한 주기에만 호출한다(추천 질문은 캐시를 실제로 교체한 주기, 토큰은 policy token 을 실제로 받은 주기, 피드백 배치는 예외 없이 끝난 주기). 허용 간격은 루프 주기의 두 배 + 여유(1800→3900, 600→1500)라 한 주기를 건너뛴 것만으로는 경보가 나지 않는다. task 이름은 TASK_* 상수로 모아 루프 본문의 오타를 막았다. 검증은 supervisor 를 가짜 시계로 직접 호출하는 단위 테스트 9건(stale 판정·회복·기준선·죽은 task 를 감추지 않음·전이 판정)과, kiwipiepy·psycopg2 미설치로 import 할 수 없는 세 파일(api.py/util/token_store.py/service/feedbackservice.py)에 대한 AST 정적 검사 5건(세 루프의 heartbeat 호출·그 호출이 성공 분기 안인지·등록의 max_silence·/health 의 stale 노출)으로 했고, 옛 코드를 되돌려 넣어 정적 검사 5건이 실제로 실패하는지 확인했다. python3 -m pytest -q 984 passed(기존 969), python -m pyflakes . undefined name 0건. docs 5종(CURRENT_STATE_AUDIT/OPERATIONS/API_REFERENCE/CODEBASE_MAP/TESTING) 갱신. 커밋 277d90e. 남은 한계는 문서에 명시: fetch_unprocessed_feedback 이 DB 조회 실패를 빈 목록으로 돌려주므로 조회가 계속 실패하는 상태는 피드백 배치의 성공으로 기록된다.
• 보류 아이디어: A-105 후속 — 공통 오류 응답 model 도입과 traceback 노출 제거(A-106 연계) — 가치 4 / 위험 3 / L
• 보류 아이디어: Milvus 적재 실패가 조용히 성공으로 보고되는 문제(insert_to_milvus_cf 가 traceback 문자열을 return 하고 호출부가 무시) — 가치 3 / 위험 2 / S
• 보류 아이디어: fetch_unprocessed_feedback 이 DB 조회 실패와 “처리할 피드백 없음” 을 구분하지 않는 문제(A-112 후속) — 가치 3 / 위험 1 / S
• 보류 아이디어: bare except → 구체 예외로 범위 축소(service/pipelineservice.confluence_pipeline_kcblaw, api.py 의 /run_confluence_pipeline_spacefile 등 잔여) — 가치 3 / 위험 3 / M
• 보류 아이디어: A-107 후속 — 재시도·circuit breaker·공용 requests.Session 도입 — 가치 3 / 위험 3 / M

dataworks

• 선택: API Entitlement 쓰기 경로에도 status 허용값 검증 추가(계약 쪽과 대칭) (가치 3 / 위험 1 / 작업량 S)
• 결과: 성공
• 요약: POST /admin/dataworks/products/{key}/entitlements 는 expires_at 형식만 검사하고 status 는 그대로 저장해, enabled·actve 같은 오타가 들어오면 store.EntitlementActive 가 active 만 인정하므로 발급 순간부터 고객 API 키가 403 inactive_entitlement 를 받는데 admin 목록에는 정상 발급된 접근권으로 보였다(계약 쪽 invalid_contract_status 와 같은 유형의 fail-closed 오설정). contractScopeStatusKnown 과 대칭으로 entitlementStatusKnown 을 두고 active(기본)·draft·suspended·revoked 만 허용하며 그 외에는 400 invalid_entitlement_status 로 거부하고, 소문자·trim 정규화 후 빈 값은 active 로 채워 응답이 실제 저장 행과 일치하게 했다(감사용으로 남기는 revoked 행은 관례대로 계속 저장 가능). 검증: HTTP 회귀 테스트(오타 상태 거부·미저장, ` ACTIVE ` 정규화 저장, revoked 허용, 생략 시 기본값이 응답·저장 행 모두 active)와 entitlementStatusKnown 표 테스트를 추가하고 검사를 꺼서 회귀 테스트가 실제로 실패(200 으로 status:"enabled" 저장)하는 것을 확인, go build ./...·go vet ./...(0건)·go test ./... 전체 통과, go run ./cmd/api-surface-audit gap 0, gofmt 상태는 변경 전과 동일(dataworks_runtime.go 는 기존 CRLF 파일). docs/OPERATIONS.md 5절에 문서화. web 변경이 없어 웹 체크는 미실행이고, 릴리즈 커밋은 남기지 않았다.

• 보류 아이디어: action center 의 활성 판정이 ent.Status != "active" 라 대소문자가 다른 레거시 행을 런타임과 반대로 판정(store.EntitlementActive 재사용 필요) / 이미 지난 expires_at 으로 발급되는 죽은 엔타이틀먼트를 쓰기 경로에서 거부 / internal/dataworks 도메인 함수(EvaluatePublishGateV2·EvaluateRetirementCandidate) 단위 테스트 보강 / 동일 API 키에 활성 엔타이틀먼트가 둘 이상일 때 운영 화면에서 경고 / action center 가 상품이 사라진 고아 Contract Scope·Entitlement 도 그대로 집계

• 릴리즈: v0.9.50 (2026-09-10, run 2026-09-10-114120-dataworks-improve)

appstore

• 선택: 반려된 앱을 소유자가 다시 검토로 올릴 수 있게 (가치 4 / 위험 2 / 작업량 S)
• 결과: 성공
• 요약: 소유자에게 제출 경로는 PUT /apps/{app} 하나뿐인데(별도 submit endpoint가 없다) store.UpdateApp은 status를 전혀 건드리지 않고, updateApp·mcpUpdateApp의 재제출 분기는 before.Status == published일 때만 돌았다. 그래서 반려된 앱은 소유자가 지적받은 내용을 그대로 고쳐도 rejected에 머물고 pending review가 하나도 생기지 않아, 관리자가 손으로 상태를 바꿔 주지 않으면 영구히 카탈로그에 못 올라갔다 — 정작 사용자 가이드는 “반려 사유를 반영하고 다시 제출”하라고 안내한다(docs/guides/user/index.html:90). 로컬 postgres:16-alpine 컨테이너로 전체 수명주기를 직접 확인했다: 반려 뒤 소유자가 serviceUrl을 고쳐 UpdateApp을 호출하면 status는 rejected, pending review는 0개였고, 재제출을 끼우면 pending_review + level 1 review가 생겨 검토자가 승인해 published까지 도달했다. 새 순수 함수 resubmitAfterEdit를 REST·MCP 두 수정 경로가 함께 쓰게 해 workflow가 켜져 있으면 반려된 앱을 재제출하고, 게시된 앱은 기존대로 재승인 정책을 따르게 했다. workflow가 꺼져 있으면 SubmitApp이 곧바로 published로 만들기 때문에 반려된 앱을 검토 없이 카탈로그로 밀어 넣지 않도록 Enabled 조건을 반드시 유지했다. MCP app_update tool 설명과 OpenAPI updateApp에도 이 재제출 의미를 문서화했다. 검증: 상태·정책 조합 8개 테이블 테스트를 추가하고 store 통합 테스트에 “수정만으로는 rejected에서 벗어나지 못하고 재제출은 level 1로 되돌아온다”는 단언을 더한 뒤 gofmt -l, go vet ./..., go test -race(CI와 같은 패키지 목록), DSN을 준 go test -race ./internal/store ./internal/httpapi ./internal/database 재실행, go build ./cmd/server, check-env-contract.sh·check-docs.sh 모두 통과. 프런트엔드는 변경하지 않아 npm 검사는 생략(앱 수정 완료 화면이 이미 “승인 Workflow 설정에 따라 즉시 게시되거나 검토 대기 상태가 됩니다”라고 안내한다). 커밋 698b5e1.

• 보류 아이디어: 소유자가 반려 사유를 볼 수 있는 화면이 없음 — 이번에 재제출 경로는 열었지만 /me/apps 응답에 reason이 없어 무엇을 고쳐야 하는지 추측이 된다(가치 3/위험 2/M) · clientAddress가 RemoteAddr만 보아 reverse proxy 뒤에서는 익명 사용자 전체가 하나의 rate limit bucket을 공유 — 신뢰 프록시 설정이 필요한데 환경변수 계약이 네 개로 고정(가치 3/위험 3/M) · pending_review 상태의 앱을 수정해도 검토가 level 1로 되돌아가지 않아 다단계 승인에서 level 2 검토자가 level 1이 본 적 없는 내용을 승인함 — 정책 결정이 먼저 필요(가치 2/위험 3/S) · fetchBrandingSource의 오류 메시지에 upstream 상태 코드와 err 원문이 샘(가치 2/위험 2/S) · 검증 하드닝 계열(adminUpdateUser·개인 키 이름·roleRequest·관리자 write path param)은 사람이 같은 접근의 PR 6854375를 반려했으므로 모두 rejected로 내렸다.

• 릴리즈: v2.5.6 (2026-09-10, run 2026-09-10-114115-appstore-improve)

git-ctx

• 선택: 파이썬 프로젝트가 실제로 갖는 락파일(uv.lock·pdm.lock·Pipfile.lock)을 읽도록 수정 (가치 4 / 위험 1 / 작업량 M)
• 결과: 성공 (commit 470ee9f)
• 요약: internal/manifest/lockfile.go의 RecognizeLock이 파이썬 락파일로 poetry.lock 하나만 알고 있어서, uv·PDM·pipenv로 해석하는 저장소는 인벤토리에 pyproject.toml의 범위(>=2.31, ~=4.2)만 남았습니다 — 범위는 권고 판정이 결정하지 못하는 쪽이고, 해결된 버전은 즉답할 수 있는 유일한 근거인데 그 파일이 아예 인식되지 않아 읽히지 않았습니다. uv와 PDM은 Cargo·Poetry와 같은 [[package]] 블록을 쓰므로 기존 parseTOMLLock으로 보냈고(이름·버전이 열 0에 있어 uv 블록의 requires-dist·[package.metadata]의 중첩 name =은 들어오지 않습니다), JSON인 Pipfile.lock은 별도 리더를 붙였습니다 — _meta는 패키지 집합이 아니고 값의 모양도 달라서 문서 전체를 한 map으로 디코드하면 그 키 하나 때문에 파일이 통째로 버려지므로 default·develop만 이름으로 읽습니다. pipenv는 핀을 설치할 요구사항 형태(==2.31.0)로 저장해 다른 락파일이 쓰는 숫자와 다른 버전 그룹이 되므로 연산자를 떼고, VCS ref로 고정된 패키지는 버전이 없으므로 제외합니다. 검증: 새 테스트 2건(TestThePythonLockFilesAProjectActuallyHas — 세 형식의 인식·해결 버전·certifi/_meta/VCS 항목 비유입, TestPipfileLockStatesTheVersionAlone) 추가하고 수정 전 실패를 직접 확인. gofmt -l, go vet ./..., go build -tags sqlite_fts5 ./..., go test -tags sqlite_fts5 ./... 전체 통과(exit 0), manifest·indexer·search는 -race도 통과. docs/configuration.md의 지원 락파일 목록도 갱신.
• 보류 아이디어: pipenv의 매니페스트 Pipfile([packages]·[dev-packages] TOML)은 여전히 인식되지 않아 범위 선언이 인벤토리에 없음 (가치 2 / 위험 1 / S). clampResponse의 truncation notice 예약치 320B보다 실제 공지가 길어 예산을 십수 바이트 초과 (가치 2 / 위험 2 / S). parsePOM이 <dependencyManagement> 선언까지 실제 의존성으로 집계 (가치 3 / 위험 3 / M). YAML 블록 스칼라(password: |)의 값은 어떤 마스킹 규칙도 닿지 않음 (가치 3 / 위험 2 / M). mcp.filterLibraries/cacheKey가 호출자 슬라이스를 제자리 변경 (가치 2 / 위험 1 / S).

jikim

• 선택: SessionByToken·Authenticate가 DB 장애를 인증 실패로 접는 문제 수정 (가치 3 / 위험 2 / 작업량 M)
• 결과: 성공
• 요약: users.go의 Authenticate와 SessionByToken이 QueryRow 실패를 원인과 무관하게 ErrUnauthorized로 바꿔, DB 장애가 “자격증명 거부”·”세션 만료”로 보고되고 인증 미들웨어는 401/403을, 로그인 rate limiter는 장애를 실패 시도로 계산해 5분 창 동안 계정을 잠갔습니다. v0.2.5~v0.2.7의 오류 매핑 정리와 같은 방식으로 lookupFailed로 pgx.ErrNoRows와 그 밖의 오류를 나눠 행 없음만 sentinel로 남기고, withAuth·sessionStatus는 storeError로 500을, withBaoAuth는 새 baoSessionFailure로 만료 토큰(403 permission denied)과 조회 불가(500 failed to look up token)를 갈랐으며, login·baoUserpassLogin은 장애를 실패 시도로 계산하지 않고 500을 반환하고 driver 문자열을 응답에 담지 않습니다. 검증은 hook 기반 단위 테스트 7개(auth_outage_test.go 6개 + store lookupFailed 1개)를 추가하고 ./scripts/verify.sh 전체(Go test·vet·gofmt, React test·lint·build, docs, compose) 통과로 확인했습니다. 커밋 d79383b.

• 보류 아이디어: 로그인 성공 판정 전에 rate limiter를 succeeded로 초기화하는 순서 정리 (2/1/S) / settings GET이 주입하는 파생 필드가 PUT 왕복 시 workflow 설정에 저장되는 문제 정리 (2/1/S) / 감사 로그 보존(audit_retention_days) 자동 정리 구현 (3/3/M) / baoKVWrite가 SecretExistsByPath로 create·update capability를 고르면서 생기는 TOCTOU 정리 (2/2/S) / Transit rewrap 엔드포인트 추가 (2/3/M)

• 릴리즈: v0.2.8 (2026-09-10, run 2026-09-10-121123-jikim-improve)

igame

• 선택: 관리자 비밀번호 재설정이 대상 사용자의 세션을 지우지 않는 문제 (가치 4 / 위험 2 / 작업량 S)
• 결과: 성공
• 요약: updateUser(internal/api/admin.go)는 password_hash만 쓰고 auth_sessions는 건드리지 않았다. 비밀번호 재설정은 관리자가 탈취된 계정을 되찾는 수단인데, 옛 비밀번호로 열린 세션이 남은 수명(최대 12시간) 동안 그대로 살아 있어서 훔친 쿠키는 계속 통했고 계정은 사실 회수되지 않았다 — 본인 변경 경로인 changePassword는 처음부터 나머지 세션을 지우고 있었으므로 의도는 이미 확립돼 있었다. 이제 삭제가 같은 statement의 DELETE CTE로 UPDATE와 함께 일어나 “새 비밀번호 + 옛 세션” 상태가 생길 수 없고, 살아남는 것은 관리자가 이 화면에서 자기 비밀번호를 재설정할 때의 요청 자신의 세션 하나뿐이다(중간에 로그아웃시켜서 지켜지는 것은 없다). 역할·상태는 authenticate가 매 요청 다시 읽으므로 쓸어낼 필요가 없다. 감사 항목에는 폐기한 세션 수를 sessions_revoked로 남긴다. 판정 주체가 PostgreSQL이라 실제로 돌려서 검증했다: IGAME_TEST_DSN이 있을 때만 도는 테스트(internal/api/admin_pg_test.go, 4개)가 빈 DB에 마이그레이션을 적용하고 재설정·본인 재설정·프로필만 수정·없는 사용자 네 경우를 확인하며, 훔친 쿠키가 정말로 인증되지 않는지 authenticate로 직접 확인한다. make test-db DSN=... 타깃과 README·docs/security.md 안내를 함께 넣었다. 검증: gofmt -l, go vet ./cmd/... ./internal/... ./migrations/..., go build ./..., go test·go test -race 전체 통과, docker postgres:17-alpine으로 새 테스트 4개 통과 및 폐기를 무력화하면 재설정 관련 2개만 실패하고 나머지 2개는 통과함을 확인, npm --prefix web run lint와 npm --prefix web test 221개 통과(프런트엔드 소스는 건드리지 않았고 감사 상세 렌더러가 이미 임의 키를 처리한다).

• 보류 아이디어: 일일 플레이 제한이 진행 중인 세션을 세지 않는 문제가 main에 그대로 남아 있음 — 2026-09-07 회차의 수정은 원격에 올라간 적 없는 브랜치에만 있다 / 동점일 때 row_number()와 바깥 ORDER BY가 독립적으로 정렬돼 rank 번호와 행 순서가 어긋날 수 있음 / 잘린 감사 로그 CSV가 200과 완전한 헤더로 내려가고 audit.export가 잘린 개수를 전체인 양 기록함 / Migrate 체크섬 불일치·트랜잭션 경계 통합 테스트 — 이번에 들어온 IGAME_TEST_DSN 하네스로 이제 가능 / 게임에 묶이지 않은 전역 업적은 content.go의 JOIN이 NULL과 매치되지 않아 클라이언트에서 해금될 수 없음

• 릴리즈: v0.7.9 (2026-09-10, run 2026-09-10-121120-igame-improve)

jupiq

• 선택: 오류 메시지 자르기가 한글 문자를 쪼개지 않게 수정 (가치 3 / 위험 1 / 작업량 S)
• 결과: 성공
• 요약: store.truncate(1000바이트)와 integration.safeConnectionError(500바이트)가 바이트 단위로 슬라이스해, 한글 오류 메시지가 상한을 넘으면 자르는 지점이 UTF-8 시퀀스 중간에 떨어졌다. 앞의 값은 hubs.last_error·integration_health.last_error에 그대로 들어가는데 PostgreSQL이 잘못된 바이트 시퀀스를 거부하므로 실패를 기록하려는 UPDATE 자체가 실패해 망가진 Hub가 계속 healthy로 남고, 뒤의 값은 연결 검증 Drawer에 그대로 보이므로 JSON 인코더가 U+FFFD로 바꿔 관리자에게 깨진 글자가 보인다. 두 곳 모두 룬 경계까지 되돌아가 자르고 애초에 유효하지 않은 입력은 대체 문자로 치환하도록 고쳤으며, 상한 근처 모든 오프셋에서 결과가 유효한 UTF-8이고 원본의 접두사이며 한 룬(3바이트) 넘게 버리지 않는지 검증하는 테스트 4개를 추가했다. 수정 전 코드로 되돌린 변형에서 새 테스트가 실제로 실패하는 것을 확인했고, gofmt -l, go vet ./..., go test -race ./..., scripts/check-version.sh, scripts/check-screenshots.mjs, npm run lint, npm test(18파일 59개) 모두 통과했다.

• 보류 아이디어: 로그인 리미터 succeeded가 ip 키를 의도적으로 유지하는 동작에 대한 테스트·문서화 / internal/store 커버리지 중 DB 없이 테스트 가능한 순수 함수 경로 보강 / auth/oidc.go가 RandomToken 오류를 무시하고 state·nonce·verifier를 만드는 부분 정리 / internal/api 통합 테스트를 로컬에서 돌리는 방법 문서화와 make test-integration 타깃 / 쿼리로만 GPU로 분류되는 별칭 지표가 feature_enabled 없이 빈 목록을 받는 잔여 간극

• 릴리즈: v1.4.12 (2026-09-10, run 2026-09-10-135106-jupiq-improve)

umm

• 선택: 내보내기가 쓰는 이름을 자기 생각에 붙인 사람 (가치 4 / 위험 1 / 작업량 S)
• 결과: 성공
• 요약: Markdown 내보내기는 백업이고 끝에 ## Connections·## Lines of thinking 두 절을 붙이는데, 가져오기가 그 둘을 제목만 보고 알아봤습니다. 그런데 “Connections”는 생각에 붙이기 아주 흔한 제목이고(가져오기 자신의 주석도 “an ordinary thing to title a thought”라고 적어 둠), umm의 파일 안에서는 제목만으로 사람의 생각과 내보내기의 목록을 구별할 수 없습니다. 목록으로 읽힌 그 절은 산문에서 연결을 하나도 뽑지 못한 채 통째로 버려져 생각이 복원에서 사라졌고, - id:도 등록되지 않으므로 그 생각으로 그어져 있던 연결은 답할 생각이 없는 id를 가리키게 되어 함께 사라졌습니다 — 사람이 가장 다시 쓸 법한 제목 하나가 가장 비싼 값을 치르던 자리입니다. 내보내기는 이미 그 차이를 적어 두고 있어서(생각 절은 언제나 id·type·source·color·canvas 메타데이터로 끝나고, 닫는 두 절은 결코 그렇지 않음 — 마지막 줄이 연결이거나 갈래) 절 꼬리로 판정하게 했습니다. v0.71.5가 메타데이터를 읽는 그 꼬리와 같은 자리라 형식은 그대로이고, 이미 받아 둔 백업 파일도 그대로 복원됩니다. 검증: 새 vitest 2개 추가 후 옛 판정(return exportSections.has(title))으로 되돌리면 둘 다 실패함을 확인, 실제 PostgreSQL 17(도커 umm-test-pg, DSN postgres://umm:umm@127.0.0.1:15433/umm)에 대한 go test -p 1 ./... 전체 통과 · go vet ./... · tsc · oxlint/Prettier · i18n 994키 · vitest 158개 · scripts/check-version.sh 통과. 버전은 올리지 않았습니다(릴리스는 별도 세션).
• 보류 아이디어: 재시도 초안(formatImportedThoughts)은 메타데이터가 하나도 없는 생각에 ## Connections 제목을 그대로 써서 같은 결함이 한 발짝 옆에 남음 — 붙여넣기 혼합 + 일부 실패에서만 닿음 / 업로드 라벨에 든 경로가 safeFilename에서 구분자만 지워져 C:\a\b.png가 Cab.png로 붙음 — 마지막 조각만 취해야 함 / Markdown 백업에 그림이 담기지 않는 사실이 릴리스 노트에만 있고 내보내기 메뉴·user-guide·features.md 어디에도 없음 / usableSections가 서로 다른 부에 같은 제목이 오는 제안을 막지 않아 같은 이름의 부가 두 번 열림 / exportOutline의 내려받기 이름이 언제나 umm-outline.md라 여러 공간의 개요를 받으면 구분할 수 없음

← 대시보드 · Atom 피드 · 원본 데이터 runs.jsonl