Production problem에서 시작한
Open Source Engineering Systems.

활동·릴리스·기여자·저장소 연령은 빌드 시점 GitHub snapshot에서, 문서 커버리지는 사이트 content index에서 계산합니다. 인기나 품질 점수가 아니라 운영 신호입니다.

저장소·문서 snapshot에서 확인되는 사실 기반 유지보수 신호입니다. 기존 tracker는 실제 issue 상태를 표시하고, Untracked 신호에는 keyword가 일치하는 open issue를 Candidate로만 제안하며 자동 tracker로 승격하지 않습니다.

Governance·Security는 repository tree audit, Release·Community는 GitHub snapshot, Docs는 사이트 index, Adoption은 명시적 evidence registry만 사용합니다. Tracker 상태와 candidate issue match는 검토 보조 신호일 뿐 현재 repository evidence를 덮어쓰지 않습니다.

Adoption evidence는 external adopter, downstream 사용이 확인된 external contributor, user report, public deployment, downstream integration만 허용하며 모든 항목에 source URL이 필요합니다. star·fork·clone 수·단순 contributor 집계는 의도적으로 제외합니다.

각 항목은 audit 또는 snapshot에서 명시적으로 확인되지 않은 근거로부터 생성됩니다. Canonical tracker가 기준이며, 같은 저장소의 keyword-matched open issue는 검토용 Candidate로만 표시합니다.

Repository audit, issue candidate matching, adoption discovery 모두 보수적으로 동작하며 Candidate 신호는 tracker나 adoption evidence로 자동 승격되지 않습니다.

Pages 빌드 시 GitHub code search가 정확한 repository URL 언급을 candidate로 추가할 수 있지만 intake는 readiness evidence와 분리됩니다. 자동 후보는 source 검토와 승격 전까지 Adoption readiness를 변경하지 않습니다.

승격 규칙: source가 실제 사용을 명시해야 candidate → reported, source와 프로젝트 관계를 검토한 뒤에만 reported → verified로 올립니다. 동일 source URL에 대한 수동 검토 기록이 자동 후보보다 우선하므로 rejected 판단도 이후 discovery에서 유지됩니다.

Standards에서 Workload까지 한 흐름으로 읽습니다.

OpenForge의 공통 practice를 공유하지만 각 프로젝트는 독립 설치·검증·릴리스를 지향합니다. 아래 지도는 런타임 의존성이 아니라 engineering practice와 실제 사용 시나리오의 연결입니다.

역할·검증 경계는 문서 기반으로 유지하고, commit·release·contributor·최근 push는 Pages 빌드 시 갱신되는 GitHub metadata snapshot을 사용합니다.

코드만 늘지 않고 문서도 함께 확장됩니다.