문서 / docs/manual-impact.md

매뉴얼 영향 및 릴리스 정합성

기능별 매뉴얼 영향과 릴리스 정합성 기록.

공개 경로, 콘텐츠 gate, 운영 계약 변경을 독자별 매뉴얼과 연결한다. 상태는 검증 완료, 영향 없음, 외부 대기만 사용한다. 코드가 GREEN이어도 외부 배포와 rollback 증거가 필요한 행은 실제 실행 증거가 생길 때까지 완료로 닫지 않는다.

기능·경로 /guide 공개 가이드 README.md 개발자 docs/evidence-maintenance.md 근거 관리자 docs/operations.md 운영자 현재 상태
/ 개요 사이트 목적·구성·읽는 순서 안내 안정 경로·검증 설명 영향 없음 — snapshot 절차 불변 smoke 대상 검증 완료
/guide 여섯 섹션·작업 순서 탭(신규제작 10·SM 9)·매뉴얼 gate 기여 흐름과 연결 영향 없음 — 근거 선별 계약 불변 smoke 대상 검증 완료
/5240lab 근거 단계와 연결 콘텐츠 구조·관리 링크 manifest→검증→snapshot 절차 smoke 및 공개 오류 대응 검증 완료
/roadmap 재평가 단계와 연결 콘텐츠 구조 roadmap 참조 전 근거 ID 유지 smoke 대상 검증 완료
/docs 문서 타임라인에서 실제 문서로 연결 매니페스트·스냅샷 파이프라인 설명 영향 없음 — 근거 선별 계약 불변 smoke 대상, 문서 상세 한 편 포함 검증 완료
/api/health 영향 없음 — 공개 작업법 변경 없음 build/runtime 경계 영향 없음 — snapshot 응답 아님 최소 JSON·release 확인 검증 완료
robots, sitemap, canonical, 404 영향 없음 — 가이드 본문 변경 없음 다섯 안정 경로 설명 영향 없음 — 근거 스키마 변경 없음 index·smoke·복구 계약 검증 완료
versioned release와 rollback 제품+매뉴얼 통합 release gate 로컬 명령과 검증 설명 공개 snapshot 동봉 구현 인터페이스·훈련 절차 검증 완료
DNS/TLS와 외부 공개 영향 없음 — 작업 가이드 변경 없음 실제 활성 release와 검증 경로 기록 외부 URL 유출 금지 원칙 유지 DNS·TLS 검사와 incident 절차 검증 완료
브라우저 검증 규정 구현·릴리스 게이트와 완료 템플릿에 브라우저 검증 반영 AGENTS.md 규칙 블록과 연결 한 줄 영향 없음 — 근거 선별 계약 불변 영향 없음 — 배포·incident 절차 불변 검증 완료

Phase 8 통합 검증 결과

  • 제품 route와 manual route 목록은 동일한 공개 페이지와 /api/health를 사용한다. 최초 검증 시점에는 네 페이지였고, 공개 문서 조회가 들어간 뒤로는 /docs를 포함한 다섯 페이지와 문서 상세 경로를 함께 쓴다.
  • README의 현재 명령은 package.json script 또는 존재하는 파일과 대조한다.
  • deploy/build-release.sh, deploy/deploy.sh, scripts/smoke.mjs의 실제 명령과 candidate, activation, external smoke failure, rollback 계약을 shell test로 검사한다.
  • 상대 문서 링크, 공개 URL, 권한 표현, health 메시지와 release claim을 integration 및 manual validator로 검사한다.
  • 로컬 fixture candidate와 rollback 훈련을 실행했다.
  • 실제 DNS, systemd/Nginx, TLS, HTTP→HTTPS, HSTS와 외부 smoke를 2026-08-14에 확인했다.
  • 활성 release는 harness-20260814-0b665e7-r2이며 외부 smoke는 PASS다.
  • 제품 경로, 운영 매뉴얼과 실제 배포 계약을 같은 release 기준으로 재검증해 T068을 닫았다.

다음 갱신 시 feature/task ID, 변경 파일, 영향받은 매뉴얼, 검증 명령과 결과를 같은 행에 연결한다. manual-impact: none은 영향 독자·절차·공개 계약이 없다는 구체적 이유가 있을 때만 허용한다.

공개 문서 조회 (2026-08-17)

  • manual-impact: yes
  • 근거: 공개 경로가 네 개에서 다섯 개로 늘고 /docs 아래 문서 상세 경로가 생긴다.
  • 조치: 운영 매뉴얼의 외부 스모크 경로 목록에 /docs를 더하고, 공개 대상 문서는 content/docs-manifest.ts에 선언한 것만이라는 규칙을 운영 매뉴얼에 남긴다.
  • 공개 경로 확인: /docs 목록과 /docs/<묶음>/<문서> 상세가 모두 200으로 응답해야 한다.

현재 상태 기록 (2026-08-18)

  • 가동 릴리스는 여기에 적지 않는다. GET /api/health의 releaseId가 정본이고, 문서에 적은 ID는 다음 배포에서 곧바로 낡는다. 이 기록을 쓴 시점에는 배포 미반영 커밋이 없었다.
  • 공개 경로 다섯 개와 문서 상세 37편이 200으로 응답한다.
  • 근거 19건을 다시 대조해 content/release.json의 근거 검증일을 2026-08-18로 갱신했다.
  • content/release.json의 릴리스 ID harness-2026.08-foundation은 그대로 둔다. 이 값은 근거·콘텐츠 묶음의 이름이고, 배포마다 바뀌는 릴리스 ID는 활성 릴리스의 launcher가 런타임에 넣는 값이다. 둘은 서로 다른 것을 가리킨다.
  • 002 타이포그래피와 003 공개 문서 조회의 검증 결과는 검증 보고서, 배포 이력은 배포 보고서에 이어 적었다.

SM 개선·추가를 가이드에 세움 (2026-08-18)

  • manual-impact: yes
  • 근거: /guide가 신규제작 열 단계만 설명하고 있어서, /docs의 SM 개선·추가 아홉 단계가 가이드로 이어질 자리가 없었다. 가이드에 일곱 번째 섹션을 더해 두 갈래를 나란히 읽게 한다.
  • 조치: 단계 정의는 content/journey.ts 하나를 두 화면이 함께 읽는다 — 같은 것을 두 곳에 적으면 한쪽만 낡는다.
  • 공개 경로 확인: /guide#sm-improvement가 목차와 본문 양쪽에서 도달 가능해야 한다.

작업 순서를 한 절로 합치고 탭을 붙임 (2026-08-18)

  • manual-impact: yes
  • 근거: 같은 열 단계를 랜딩(/)과 가이드가 각각 그리고 있었고, SM 아홉 단계는 또 다른 절에 있었다. 같은 것을 세 곳에 두면 한 곳만 낡는다.
  • 조치: 가이드의 "작업 순서" 한 절에서 두 갈래를 탭으로 갈라 비교하게 하고, 랜딩은 그 절로 보내기만 한다. 탭은 링크와 :target으로 만들어 JavaScript 없이 동작한다.
  • 공개 경로 확인: /guide#playbook, /guide#track-new, /guide#track-sm이 모두 도달 가능하고, 기본은 신규제작이 열려 있어야 한다.

개요의 성격을 사이트 안내로 바꿈 (2026-08-18)

  • manual-impact: yes
  • 근거: 작업 순서를 가이드 한 곳으로 합치면서 개요가 얇아졌다. 개요를 하네스 설명의 축약본으로 두면 가이드와 같은 말을 두 곳에 적게 되므로, 성격을 바꿔 이 사이트 자체의 목적·구성·사용법을 안내하는 화면으로 만든다.
  • 조치: 개요는 다른 화면의 내용을 요약하지 않고 "어느 화면이 무엇에 답하는가"와 "목적별 읽는 순서"만 적는다. 사이트가 스스로에게 건 규칙도 여기에 명시한다.
  • 공개 경로 확인: /의 네 절(purpose·structure·how-to-read·rules) 앵커가 도달 가능해야 하고, 개요에 작업 단계가 다시 그려지면 테스트가 실패한다.

문서 타임라인을 작업 순서로 합치고 빈 단계에 권장 문서를 세움 (2026-08-18)

  • 배경: /guide가 같은 것을 두 절에 나눠 세우고 있었다. 02 문서 타임라인의 네 문서는 03 작업 순서의 2~5단계와 같은 것이고, 그 결과 같은 관문이 implementationDocuments[].gate와 executionDetails[].gate에 별개 문장으로 두 벌 존재했다. 그 이원화가 /docs로도 새어 한 화면에 두 어투가 섞였다.
  • 조치: 문서 타임라인 절을 없애고, 문서를 단계에 붙은 슬롯으로 옮겼다 (content/guide.ts의 stageDocuments). 실물이 있는 슬롯은 /docs의 그 문서로 링크하고, 없는 슬롯은 남겨야 할 문서를 권장으로 세워 하이라이트한다. 게이트 문구는 workflowPlaybook 하나로 단일화했다.
  • 매뉴얼 영향: manual-impact: affected — /guide 절 구성이 여섯에서 다섯으로 줄고 번호가 한 칸씩 당겨졌다. 네 문서 앵커(doc-type-*)는 /docs의 guideAnchorByStage가 딥링크로 쓰고 있어 그대로 유지했다. 공개 경로 다섯은 불변이라 헌법의 경로 조항은 건드리지 않았다.
  • 이행 확인: npm run verify:content가 실물이 없는 슬롯을 목록으로 출력한다. 지금은 다섯이다 — request.md, reassessment.md, current-state.md, change-definition.md, impact-analysis.md. 권장한 문서가 실제로 작성되어 newBuildStageExamples에 연결되면 이 목록에서 빠지므로, 다음 배포의 같은 출력과 비교하면 이행 여부가 그대로 보인다.
  • 검증: npm run test(unit 187 · integration 57), npm run typecheck, npm run lint, npm run build, npx playwright test.
  • 후속(같은 날): 권장 슬롯의 안내를 "이 문서를 만들어야 합니다"로 바꾸고, 문서마다 누구의 결정을 담는지 세 갈래 라벨을 붙였다 — 사용자가 씁니다(request.md, change-definition.md) · AI가 쓰고 사용자가 승인합니다(design.md, spec.md) · AI가 채웁니다(나머지 아홉). 갈래는 "누가 타이핑하는가"가 아니라 "누구의 결정을 담는가"다. 에이전트는 어느 문서든 초안을 칠 수 있지만, 목적·비목표나 "무엇을 고칠지"는 관찰로 나오지 않아 대신 정하면 추측이 된다.
  • 후속 2(같은 날): 갈래를 라벨만이 아니라 표시로도 갈랐다 — 사용자가 쓰는 문서는 주황 (--warning), 승인이 걸린 문서는 강조색(--primary), 에이전트가 채우는 문서는 중립 (--border). 색이 유일한 단서가 되지 않도록 라벨이 같은 것을 글로도 말한다 (MASTER.md의 "Color cannot be the only state indicator").
  • 폰트 점검(같은 날): 선언한 서체(IBM Plex Sans·Noto Sans KR·JetBrains Mono)가 하나도 적재되지 않는다. 라이브 계측에서 폰트 요청 0건, document.fonts 0개 — 방문자 OS 폰트로 떨어진다. MASTER.md의 "Fonts are loaded with next/font or self-hosted assets"와 어긋난다. 또 .technical-label이 monospace라 그 안의 한글(통과 조건, 권장 문서 …)이 다시 대체된다. 둘 다 이번 변경이 만든 것이 아니라 이전부터 있던 상태이며, 처분은 미결.

선언만 하던 서체를 실제로 적재함 (2026-08-18)

  • 배경: 라이브 계측에서 폰트 요청 0건, document.fonts 0개. IBM Plex Sans· Noto Sans KR·JetBrains Mono를 선언만 하고 @font-face도 next/font도 자산도 없었다. 방문자 OS 서체로 떨어져 같은 화면이 사람마다 다르게 보였고, 08-15~17에 세 번 손본 제목 스케일의 전제가 방문자마다 달라졌다.
  • 조치: IBM Plex Sans를 버리고(한글 글리프가 없어 본문 대부분에 적용되지 않는데 스택 첫머리에 있었다) Pretendard Variable을 동적 서브셋으로, JetBrains Mono를 라틴 400·600으로 public/fonts/에 자가호스팅했다(app/fonts.css). 등폭 스택 두 번째에 Pretendard를 두어 기술 라벨의 한글이 OS 서체로 떨어지지 않게 했다.
  • 실측: /guide 기준 폰트 요청 0건·0KB → 16건·396KB. 저장소에는 3.1MB가 들어오지만 브라우저는 그 화면에 쓰인 유니코드 범위만 받는다.
  • 매뉴얼 영향: manual-impact: affected — design-system/5240lab-harness/MASTER.md의 Typography 절을 고쳤다(대표 서체 교체, 자가호스팅과 unicode-range 분할, 한글 등폭 대체 규칙 명시). 공개 경로 다섯은 불변이다.
  • 검증: npm run verify:app, npx playwright test(117 — 서체 적재 확인 2건 신규, heading-scale·heading-lines는 새 글자꼴에서도 통과).

일을 끌고 가는 것들을 설명하는 절을 세움 (2026-08-18)

  • 배경: 사이트가 문서(무엇을 남기나)와 단계(언제)는 이었지만 "누가·무엇으로"는 비어 있었다. /docs의 단계 칩에 harness-implementer 같은 이름이 뜨는데 그것이 무슨 역할인지가 사이트 어디에도 없었고, spec-kit 11개 스킬은 /guide에 아예 없었다.
  • 조치: /guide의 03 Superpowers 활용을 03 일을 끌고 가는 것들(#actors)로 확장해 세 층으로 세웠다 — 명세(spec-kit 11), 실행 규율(Superpowers 4), 역할 분리(에이전트 3). 층마다 "도구가 없다면 누가 그 자리를 맡는가"를 함께 적었다. 도구 이름만 나열하면 이 사이트가 스스로 부정해 온 것("핵심은 스킬 이름이 아니다")을 화면이 어기게 되기 때문이다.
  • 근거: 세 역할을 실제로 한 번 돌린 자취를 함께 실었다. 구현자가 통과로 낸 것을 검토자가 뒤집었고(라벨 99개 전수 실측), 검토자의 수정안을 수정자가 좁혔다(빈 라벨을 자동으로 라틴 취급하지 않도록). 커밋 bab8c99·3fe7c1c.
  • 한계 고지: 이 실행은 저장소에 정의된 에이전트가 등록되어 돌아간 것이 아니다. 프로젝트 전용 에이전트는 그 저장소를 작업 디렉터리로 열었을 때만 등록되는데 이 작업은 상위 디렉터리에서 시작했다. 정의 파일의 계약을 범용 에이전트에 실어 같은 역할을 수행시켰다. 이 사실을 화면과 content/journey.ts의 journeyActorsCaveat 양쪽에 적었다.
  • 새 검증: validateDeclaredTooling이 화면이 이름을 대는 스킬·에이전트가 실제로 .agents/skills/·.claude/agents/에 있는지 빌드 시점에 확인한다. 없다고 적힌 것이 없는 채로 배포되면 이 화면이 하려는 말을 화면 자신이 어긴다.
  • 매뉴얼 영향: manual-impact: affected — /guide 절 id가 superpowers → actors로 바뀌었다. 이 앵커를 가리키는 외부 링크는 저장소 안에 없었다(테스트만 참조). 공개 경로 다섯은 불변이다.
  • 검증: npm run verify:app(unit 188 · integration 59), npx playwright test 120 통과.
맨 위로