Phase 6~8 검증 보고서

검증일: 2026-08-14 UTC 범위: T044–T068, 로컬 source·production build·브라우저·deployment 계약과 공개 배포 release metadata: harness-2026.08-foundation

RED → GREEN

• T044 RED: integration runner가 존재하지 않는 scripts/verify-content.ts import에서 실패했다. GREEN: 전체 콘텐츠 validator 구현 뒤 route 4개, 계층 8개, 순서가 고정된 workflow 10단계, guide anchor, evidence/roadmap 참조와 날짜의 양·음수 계약이 통과했다.
• T045 RED: health, robots, sitemap, 404 모듈이 없어 public route integration이 실패했다. GREEN: 최소 health JSON, indexable robots, 네 URL sitemap, canonical metadata, 보안 header와 복구 링크가 있는 실제 404가 integration과 browser에서 통과했다.
• T054 RED: 매뉴얼을 먼저 작성한 뒤 manual integration이 존재하지 않는 scripts/verify-manual.mjs에서 실패했다. GREEN: 실제 corpus와 의도적인 절대 경로, 이메일, secret assignment, 깨진 링크, 잘못된 npm script, 알 수 없는 route fixture가 모두 기대대로 판정됐다.
• 명세 리뷰 RED: health의 근거 검증일 누락, bundle text의 source 참조 미검사, quickstart의 blocking npm run dev 다음 browser 명령을 각각 새 회귀 테스트가 검출했다. GREEN: 검증된 evidenceVerifiedOn 추가, project-root만 허용하는 bundle text 경계 검사, Playwright 자체 서버를 쓰는 단일 browser 명령과 sequencing validator로 수정했다.

Fresh local checks

Browser 49건은 네 공개 route의 WCAG A/AA axe 검사, JavaScript 비활성 핵심 콘텐츠, reduced motion, 375/768/1024/1440px 전체 route matrix, keyboard/filter/disclosure, dark mode, health/robots/sitemap/canonical/security header/static asset/404 계약을 포함한다. 동일한 네 폭에서 네 route의 full-page 화면 16장을 별도로 캡처해 제목 계층, 카드 배열, 코드 블록, footer, 모바일 내비게이션을 육안으로 확인했다. 핵심 콘텐츠 손실이나 수평 넘침은 없었다. 캡처에 보이는 작은 원형 N 표시는 Next.js 개발 모드 전용 도구이며 production build에는 포함되지 않는 제한으로 판정했다. 개발 모드 CSP는 React debugging에 필요한 eval을 개발에서만 허용하며 production CSP에는 포함하지 않는다. production은 self 기반 script/style/resource 경계를 유지한다.

Standalone 검사는 복사된 원본 content/evidence.json뿐 아니라 server·JSON·JavaScript bundle text의 manifest literal과 parent/sibling 5240lab source 경로도 거부한다. Next.js framework가 내부적으로 정확한 프로젝트 build 경로를 직렬화할 수 있어 그 프로젝트-root prefix만 허용한다. 이 내부 경로는 공개 응답이 아니며 health나 페이지 콘텐츠에 노출하지 않는다. 런타임은 생성된 공개 snapshot만 사용한다. health 응답은 status, service, releaseId, 검증된 evidenceVerifiedOn만 포함하며 캐시하지 않는다.

Phase 8에서는 실제 Next standalone release harness-local-20260813을 격리 root에 만들고 후보 포트 3631에서 --check-only smoke를 통과했다. fixture 훈련은 후보 health 실패 시 무활성화와 활성화 뒤 외부 smoke 실패 시 old-release 복구를 확인했다. 자세한 실행 경계는 deployment report에 기록했다.

External release evidence

2026-08-14 T064에서 DNS, systemd/Nginx, TLS, HTTP→HTTPS와 HSTS를 확인하고 harness-20260814-0b665e7-r2를 활성화했다. health의 release ID와 근거 검증일이 manifest와 일치했고 네 공개 페이지, robots, sitemap, 정적 자산과 404 외부 smoke가 PASS했다. 제품·매뉴얼 coordinated release gate도 재실행해 docs/manual-impact.md의 외부 공개 행을 검증 완료로 닫았다. 상세 명령과 시각은 배포 보고서에 있다.

후속 기능 검증 (002 타이포그래피, 003 공개 문서 조회)

기록일: 2026-08-18 UTC 범위: 001 이후 실제로 배포된 두 기능과, 그 뒤 화면 문구·간격을 고친 수정들.

001의 Phase 6~8 기록은 네 경로 시점의 것이다. 그 뒤 002 타이포그래피 조정과 003 공개 문서 조회가 들어가면서 공개 경로가 다섯 개가 되고 문서 상세 경로가 생겼다. 이 절은 그 변경을 포함한 현재 시점의 검증 결과를 기록한다.

002 타이포그래피 조정

• 근거 문서: specs/002-site-typography-scale/의 기능정의·계획·작업·조사·데이터 모델· 절차·점검표와 contracts/typography-ui-contract.md.
• 브라우저 계약: tests/browser/heading-scale.spec.ts와 heading-lines.spec.ts가 제목 위계와 줄바꿈을 375·768·1024·1440px에서 확인한다.
• 한글 제목·라벨의 폭 단위는 ch가 아니라 em을 쓴다. ch는 라틴 숫자 0의 폭을 기준으로 하므로 한글에서는 의도한 자수와 어긋난다.

003 공개 문서 조회

• 계획서: docs/superpowers/plans/2026-08-17-public-docs-browser.md. 여덟 작업 전부 구현·커밋·배포까지 끝났고, 계획서의 단계 표시도 실행 결과에 맞춰 닫았다.
• 헌법의 경로 제약은 다섯 개로 개정했다. 공개 대상 문서는 content/docs-manifest.ts에 선언한 것만이며, 빌드 앞단의 verify:docs가 매니페스트와 실제 파일을 대조해 공개 스냅샷을 생성한다.
• 이 사이트는 문서를 읽기만 한다. 게이트를 통과시키려고 원본 문서를 고치지 않는다. 안전 장치를 설명하는 문서는 금지 패턴을 예시로 담을 수밖에 없으므로, 매니페스트의 patternWaiver에 사람이 사유를 적은 문서 2편만 예외로 통과한다.
• 가림 검사(서버 절대 경로·사설 주소·HTML 주석)와 렌더된 HTML의 링크 목적지 검사는 예외 대상이 아니다. 목적지 검사는 원문이 아니라 렌더 결과에 건다.

이 기록 시점의 실행 결과

계획서가 완료 조건으로 적은 문서 수는 34편이었다. 그 뒤 매니페스트에 문서가 더해져 현재는 37편이며, 검증기가 세는 수와 화면에 나오는 수가 같다.

2026-08-19 브라우저 검증 규정 반영

공개 /guide의 구현·릴리스 게이트와 완료 템플릿이 브라우저 검증을 요구하고, AGENTS.md가 그 실행 규칙의 단일 출처가 되었다. 게이트 문자열은 gateForStep을 통해 /docs에도 같은 문구로 나간다.

2026-08-19 워크스페이스 경계 해석과 배포 계약 픽스처 복구

앞 절이 남긴 두 실패를 원인까지 좁혀 닫았다. 둘 다 이번 작업이 만든 것이 아니라, 저장소가 워크스페이스 안에서 한 단계 옮겨 앉은 뒤로 잠복해 있던 상태다.

• 근거 수집기의 워크스페이스 경계: verify:evidence가 feature-workflow-policy의 원본을 못 읽어 npm run build가 멈췄다. 원인은 인용 줄 번호가 아니라 경계 해석이었다 — 경계를 디렉터리 깊이(projectRoot/../..)로 셌기 때문에, 프로젝트가 한 단계 위로 옮겨 앉자 워크스페이스가 아닌 그 부모를 가리켰다. 이제 깊이가 아니라 이름으로 찾는다 (lib/workspace-root.ts). 이름은 근거 매니페스트의 workspace가 이미 선언하고 있다. 같은 깊이 셈을 쓰던 번들 경계 검사도 같은 해석으로 맞췄다.
• 문서 스냅샷: content/generated/docs.public.json이 앞선 문서 변경분을 담지 못한 상태였다. 재생성해 커밋했다. 스냅샷은 공개 문서를 고친 커밋과 같은 커밋에 담아야 한다.
• 배포 계약 픽스처: 스모크가 검사하는 경로가 /docs와 공개 문서 상세 한 편으로 늘어났는데 픽스처 서버 두 개는 늘어나지 않아, test:deploy가 404로 막혀 있었다. 두 픽스처에 경로를 채우고, 스모크 경로 목록을 scripts/smoke-page-checks.mjs 한 곳으로 모아 픽스처와 대조하는 검사를 세웠다(tests/unit/deploy-fixture-pages.test.ts). 목록이 늘어나는데 픽스처가 따라오지 않으면 이제 유닛 단계에서 걸린다.

2026-08-19 브라우저 검증 규정 문서의 공개

규정을 세운 설계·계획 두 편이 저장소에만 있고 사이트에서는 읽을 수 없었다. 매니페스트와 단계 색인에 이어 공개 문서가 41편에서 43편이 됐다 — 설계는 브레인스토밍 단계에, 구현 계획은 기술설계 단계에 붙는다. 문서 편수를 박아 둔 검사 넷(색인 대조, /docs 목록, 문서 상세 정적 경로, 사이트맵 URL 수)도 함께 43으로 옮겼다.

브라우저 검사 첫 회차에서 accessibility.spec.ts의 reduced-motion 검사 1건이 실패했다. 같은 파일 단독 실행과 전체 재실행에서 모두 통과해 부하에 따른 간헐 실패로 판단한다. 고정된 실패가 아니므로 이번 변경의 결과로 세지 않되, 재발하면 대기 조건을 손봐야 한다.

2026-08-19 독립 검토 단계의 이름을 한 벌로 맞춤

같은 단계를 두 화면이 다른 이름으로 불렀다. 작업 가이드는 「독립 검토」로 부르는데 문서 화면은 「검증」으로 줄여 불렀고, 그 줄임말이 하필 계층 이름 「검증·평가」와 겹쳐 "테스트를 실행하는 단계"로 읽혔다. 실제로 그 단계는 구현자와 분리된 관점으로 계약과 회귀를 검토하는 자리이고, 브라우저 검사를 포함한 테스트 실행은 구현 단계와 배포 단계가 진다. 이름 하나가 단계의 성격을 오해하게 만든 셈이라, 문서 화면의 세 자리와 로드맵의 발견 위치 표기를 저장소가 정한 이름으로 되돌렸다. 단계 이름은 이제 하드코딩하지 않고 저장소의 단계 정의에서 가져온다 — 다른 네 단계가 이미 쓰던 방식이다.

통과 조건 문구와 문서 배치는 건드리지 않았다. 명령 이름도 넣지 않았다 — 작업 가이드는 어느 단계에서도 구체적 명령을 적지 않고 채워 넣을 칸으로만 두는데, 이 원칙을 한 단계만 예외로 두면 도구를 바꿀 때 공개 화면 여러 곳이 함께 틀어지기 때문이다.

문서 화면이 단계 이름을 줄여 부르는 자리는 둘 더 남아 있다 — 「격리 구현」을 「구현」으로, 「통합 배포」를 「배포·운영」으로 부른다. 이 둘은 수식어만 덜어낸 것이라 단계의 성격을 잘못 가리키지 않아 이번에는 두었다. 한 벌로 맞출지는 판단이 필요하다.

2026-08-19 작업 가이드와 문서의 경계 재설정, 검사 실행 절 신설

사용자가 두 공개 화면이 중복된다고 지적했고, 읽어보니 사실이었다. /docs의 모든 단계 카드가 /guide의 게이트 문자열을 그대로 다시 찍었고, SM 아홉 단계는 두 화면이 같은 데이터를 각각 그렸다. 한 사실을 두 화면이 말하면 언젠가 한쪽이 먼저 낡는다.

경계를 다시 그었다. 통과 조건·읽는 것·남기는 것은 규정이라 /guide가 지고, /docs는 실물 문서·걸린 지점·활용된 것만 진다. 규정으로 가는 문은 단계마다 이미 있던 링크가 연다. 그 링크가 끊기면 자취만 남고 통과 조건을 찾을 길이 없어지므로, 모든 단계 카드가 가이드 앵커를 갖는다는 것을 검사로 세웠다.

같은 지적에서 나온 두 번째 요구도 닫았다. 게이트가 브라우저 검사를 요구하는데 그 검사가 무엇을 보는지가 없으면 읽는 사람이 통과 여부를 스스로 판정할 수 없다. 목차 다섯 번째에 「검사 실행」 절을 세워 도구·명령·뷰포트·접근성 규칙·보는 것·주의를 적었다. 도구 이름이 나오는 자리는 이 절 하나뿐이고, 게이트 문구와 완료 템플릿은 도구 중립으로 남겼다 — 그래야 다른 팀이 자기 도구로 같은 순서를 밟을 수 있고, 도구를 바꿀 때 고칠 데가 한 군데다. 단위 검사가 게이트에 도구 이름이 새어드는 것을 막는다.

전체 색인 머리글이 전체 38편으로 박혀 있어 실제 43편과 어긋나 있었다. 배열 길이로 세도록 바꿨다. 같은 날 고친 단계 이름 하드코딩과 같은 종류다.

RED를 여섯 건 먼저 세우고 시작했다 — 브라우저 검사 판정 기준, 목차 순서, 게이트의 도구 중립, /docs의 규정 복창 제거, 편수 계산, 가이드의 새 절. 브라우저 단계에서 두 건이 더 걸렸는데 둘 다 검사 쪽 문제였다. 하나는 SM 갈래가 CSS 탭 뒤에 있어 앵커로 열어야 했고, 다른 하나는 걸린 지점 서술이 언급하는 자산 이름을 규정의 복창으로 잘못 잡은 것이라 "읽는 것" 목록 항목 자체를 정확히 겨누도록 좁혔다.

2026-08-19 경계 재설정 설계의 공개

경계를 새로 그은 근거가 저장소에만 있으면 그 화면이 무엇을 파는지 설명하는 문서가 정작 그 화면에 없다. 설계를 브레인스토밍 단계에 붙여 공개 문서가 43편에서 44편이 됐다. 편수를 박아 둔 검사 넷(색인 대조, 목록, 상세 정적 경로, 사이트맵 URL 수)도 함께 옮겼다.

2026-08-19 실행 규율의 산출물에서 실물 문서로

사용자가 「어떻게 일할지 누가 규율하나」 층의 산출물을 조회할 수 없다고 지적했다. 넷 다 이름만 평문으로 적혀 있었고 실물은 이미 공개돼 있었다. 02절의 단계 문서 슬롯이 이미 같은 문제를 같은 방법으로 풀고 있어, 그 관례를 그대로 적용했다 — 산출물마다 실물 한 편을 가리키고 제목과 함께 링크한다. 규정을 복제하는 것이 아니라 자취로 가는 문을 여는 것이라 같은 날 그은 경계에 어긋나지 않는다.

참조가 스냅샷에서 풀리지 않으면 화면이 렌더 중에 죽으므로, 빌드 시점에 먼저 잡도록 validateSuperpowersExamples를 세우고 검증 파이프라인에 넣었다.

랜딩 히어로에서 로그인 관련 문구를 뺐다(사용자 요청).

2026-08-19 매뉴얼 단계를 여정별로 가르고 대상 매뉴얼을 명시

"동기화"는 상대가 있어야 성립하는 말인데 상대가 화면 어디에도 없었다. 무엇과 맞추라는 것인지 모르면 게이트 통과 여부도 판정할 수 없다 — 브라우저 검사에 판정 기준이 없던 것과 같은 종류의 빈칸이다. 두 여정의 대상을 5240 통합 매뉴얼 하나로 명시했다.

단계 이름도 갈랐다. 신규제작 여덟 번째는 「매뉴얼 제작」(없던 것을 만든다), SM 여덟 번째는 「매뉴얼 동기화」(있는 것을 고친다)다. 계층 이름은 두 여정을 함께 덮으므로 그대로 뒀다. 절 순서는 검사 실행이 매뉴얼보다 앞으로 갔다 — 코드가 통과했는지 먼저 판정하고 그다음에 매뉴얼 영향을 닫는다.

특정 사이트를 공개 화면에 박는 것은 이 사이트의 관례에 어긋나 보일 수 있어, 세 층의 "도구가 없다면"과 같은 방식으로 "다른 조직이라면 자기 매뉴얼이 그 자리에 온다"를 함께 적었다. 도구는 바꿔 끼울 수단이지만 동기화의 상대는 그 일의 대상 자체라는 것이 구분점이다.

작업 중 누출 검사의 결함이 하나 드러났다. 외부 URL 정규식이 소스의 문자열 리터럴에서 닫는 따옴표까지 삼켜, 승인 목록에 넣은 주소가 오탐으로 거부됐다. 문자열 구분자는 어떤 경우에도 URL의 일부가 아니므로 공유 함수의 후행 문장부호 목록에 따옴표를 넣었다.

2026-08-19 맨 위로 돌아가는 길

긴 화면에서 머리로 돌아갈 방법이 없었다. 이 사이트는 스크립트를 쓰지 않으므로 단추가 아니라 조각 링크로 두었다 — 자바스크립트가 꺼져 있어도 동작하고, 부드러운 스크롤과 모션 축소는 전역 스타일이 이미 정해 둔 것을 그대로 따른다. 스크롤 위치에 따라 나타나게 하려면 스크립트나 아직 지원이 고르지 않은 스크롤 기반 애니메이션이 필요해, 항상 두되 작게 두고 좁은 화면에서는 더 붙이는 쪽을 골랐다.

정적 링크 검사에 모델 결함이 하나 있었다. 레이아웃이 모든 화면에 심는 앵커를 경로별 목록에 넣어 두어, 건너뛰기 링크의 대상이 "/"의 앵커로 등록돼 있었다. 다른 화면에서 같은 링크를 쓰면 거짓으로 막히는 상태였다. 셸 앵커를 경로별 목록과 분리했다.

브라우저 검사 6건을 새로 세웠다 — 아래로 내려간 뒤 눌러 머리로 돌아오는지, 키보드만으로 닿는지, 네 폭에서 가로 넘침 없이 44px 이상의 누를 자리를 갖는지.

2026-08-19 매뉴얼 동기화를 선언에서 검사로

사용자가 "SM의 매뉴얼 동기화는 선언에 불과하다"고 지적했다. 맞았다 — 대상 주소를 적었을 뿐 아무것도 그것을 확인하지 않았다. 이 저장소는 자기 자신에 대해서는 이미 매뉴얼 계약 검사를 갖고 있는데, SM 여정에는 그 방법이 연결돼 있지 않았다.

두 단계로 닫았다.

규정을 검사 가능한 형태로. 셋을 세웠다 — 지목은 주소로 적고, 고친 문서는 확인일을 갱신하고, 미확인을 남긴 채 닫지 않는다. 셋 다 기계가 대조할 수 있는 형태다. 주소는 열어볼 수 있고 날짜는 비교할 수 있고 미확인은 셀 수 있다. 개선 정의 단계의 통과 조건도 "지목"에서 "주소로 지목"으로 바꿨다 — 말은 사람만 대조할 수 있지만 주소는 열어볼 수 있어, 뒤 단계의 채점이 의견이 아니라 확인이 된다.

그 위에 실제 검사를 얹었다. 판정 규칙은 조회 없이 순수 함수로 두어 단위 검사로 시험하고(11건), 네트워크는 명령 하나에만 두었다. 사유 없는 "영향 없음"을 미확인으로 떨어뜨리는 것이 핵심이다 — 그러지 않으면 빈 사유 한 줄로 통과할 수 있어 검사가 다시 선언으로 돌아간다.

대상 매뉴얼을 먼저 조사해 가능함을 확인했다. 문서마다 확인일을 본문에 노출하고 헤딩마다 안정적인 앵커가 있다. 사이트맵은 없으므로 전체 훑기는 못 하지만, 지목된 주소만 열면 되는 설계라 문제되지 않는다.

2026-08-19 공개 화면에 남아 있던 미노출 둘을 닫음

검사 실행 절이 검사 둘을 담는다. 매뉴얼 채점을 저장소 도구로만 두었더니, 게이트는 "미확인이 남으면 닫히지 않는다"고 말하는데 그 미확인이 어디서 나오는 말인지 공개 화면에 없었다. 두 문장을 이을 수 없으면 규정이 다시 선언이 된다. 명령·넣는 것·판정 세 이름· 닫히지 않는 조건을 브라우저 검사와 같은 자리에 적었다. 절 이름이 「검사 실행」인데 검사 하나만 밝히고 있던 것도 함께 바로잡힌 셈이다.

매뉴얼 단계 분리 설계를 공개했다. 44편에서 45편이 됐고 편수를 박아 둔 검사 넷도 함께 옮겼다. 설계는 브레인스토밍 단계에 붙는다.

2026-08-19 「공개」 용어 정리와 전반 점검

사용자가 물었다 — 어차피 이 사이트의 모든 것이 공개인데 「공개」라는 말이 적정한가. 세어 보니 한 단어가 네 가지 뜻을 지고 있었다.

1. 행위("방법을 공개합니다") — 주체와 목적어가 있고 정보도 있다. 그대로 뒀다.
2. 수식어("공개 문서", "공개 근거", "공개 스냅샷") — 보고 있는 사람에게 이 화면의 모든 것은 이미 공개다. "그럼 비공개 문서도 있나"를 유발할 뿐 정보가 없다. 화면 문구에서 걷어냈다. 저작 측에서는 실을 것과 안 실을 것을 가르는 진짜 구분이므로 코드와 검증 이름은 그대로 뒀다.
3. 경계·계약("공개 경로", "공개 경계") — 공개와 비공개가 실제로 갈리는 축이다. 뒀다.
4. 매뉴얼 독자 갈래 — 이것이 결함이었다. 나머지 셋(개발자·근거 관리자·운영자)은 전부 사람 역할인데 첫 항목만 공개/비공개 축이라 축이 섞여 있었고, 같은 화면의 "공개 경로"와 뜻이 겹쳤다. 여기서 「공개」가 뜻한 것은 「사용자」였다. 바꿨다.

로드맵을 지금 상태로 맞췄다. 「약속한 문서와 고친 문서의 대조를 사람 눈에만 맡기지 않는다」가 계획으로 남아 있었는데, 오늘 만든 채점이 바로 그것이다. 기준선을 만들어진 것으로 다시 쓰고 남은 일(완료 판정 절차에 물리기)을 목표로 옮겨 진행 중으로 바꿨다. 발견 위치의 단계 이름도 낡아 있었다 — 오늘 단계 이름을 두 번 고쳤는데 이 표가 두 번 다 따라오지 않았다. 발견 위치가 실제 여정에 있는 이름인지 검사로 묶어 다시 어긋나지 않게 했다.

중복과 죽은 것을 걷어냈다.

• ImprovementCard가 개선 상태 이름표를 자기 안에 다시 선언하고 있었다. 같은 표가 이미 공유 상수로 있었으므로 그것을 쓰게 했다.
• /docs에서 통과 조건과 읽는 것·남기는 것을 걷어냈을 때 그 스타일이 남아 있었다. 쓰이지 않는 규칙 넷을 지웠다.
• 어디서도 쓰지 않는 유틸리티 클래스 넷을 지웠다.

화면 다섯 개의 문장을 서로 대조해 중복을 찾아봤다. 30자 이상 같은 문장은 넷뿐이고 그중 셋은 정당하다 — 모든 화면에 붙는 꼬리말, 그리고 규정과 자취 양쪽에 나오는 스킬 이름표다. 나머지 하나(하네스 정의)는 두 화면이 같은 상수를 렌더하므로 한쪽이 먼저 낡을 수 없다. 앞서 그은 경계가 실제로 지켜지고 있다.

2026-08-19 미결 둘을 닫음

단계 이름을 한 벌로 맞췄다. 문서 화면이 「격리 구현」을 「구현」으로, 「통합 배포」를 「배포·운영」으로 줄여 부르고 있었다. 성격을 오해시키지는 않아 두었던 것인데, 하루에 같은 종류의 어긋남이 세 번 나왔으므로 판단을 바꿨다. 이제 화면이 부르는 이름은 저장소가 정한 이름에서 나온다.

같은 결함이 되풀이되지 않게 검사로 묶었다. 여정 단계의 id가 저장소의 단계 정의에 있으면 이름도 그것을 따라야 한다. 성격이 실제로 다른 자리만 예외이고, 그 예외는 여정 단위로 좁혀 선언한다 — 지금은 하나뿐이다(SM의 매뉴얼 동기화). 이름을 손으로 적는 것 자체를 막지는 않지만, 몰래 어긋나는 것은 막는다.

타이포그래피 미병합 브랜치 셋을 처분했다. 세 브랜치의 제품 변경은 이미 대체됐다 — 같은 문제를 다른 방법으로 다시 풀었고, 그 뒤 서체 자가호스팅까지 갔다. 남아 있던 테스트 자산도 대부분 대체됐다. 제목 줄 수 검사는 지금 검사가 같은 것을 하고, 40개 CSS 선언을 세는 재고 검사는 그 선언들이 이미 없어져 옮기려면 다시 쓰는 일이 된다.

대체되지 않은 것이 하나 있었다 — 글자가 잘리거나 형제끼리 겹치는 것을 잡는 검사다. 가로 넘침이 아니어서 지금 검사로는 안 잡힌다. 브랜치를 그대로 두면 자산인 척하는 죽은 가지가 되므로, 그 능력만 개선 과제로 옮기고 브랜치는 태그로 보존했다. 태그가 남아 있어 되돌릴 수 있다.

2026-08-19 값이 없는 줄을 그리지 않는다

로드맵 배포 뒤 화면을 읽다가 찾았다. 근거 ID가 없는 과제 카드가 「현재 근거 ID」라는 라벨만 남기고 값 없이 그려지고 있었다. 값이 없으면 그 줄 자체를 그리지 않는 것이 이 사이트가 단계 링크와 활용된 것에 이미 세운 기준인데, 이 카드만 따르지 않았다.