앱별 문서

소스 정본과 실행 권한은 운영 소스·실행 관리, 브랜치 관리는 git 워크트리를 따릅니다.

전체관리자와 앱관리자 안내에서 역할·월별 토큰 한도·산출물 관리 기준을 확인합니다.

운영 배포

회사 사이트는 main 브랜치에 푸시하면 GitHub Actions가 Firebase Hosting에 배포합니다. content.py의 RELEASE_APPS가 운영 메뉴와 포함할 앱을 정합니다. 문서와 위키를 먼저 빌드한 뒤 정적 사이트를 조립합니다.

python build_subapp.py aurora ../AURORA/public
python build_subapp.py pepdesigner ../PepDesigner/lib/PepDesigner/dashboard
python build_docs.py
python build_wiki.py
python build_static.py
python tools/check_release.py

백엔드 재기동은 정적 사이트 배포와 별개입니다. 각 앱의 운영 안내를 따릅니다.

이 위키

누가 보나. 전체관리자는 모든 문서를 봅니다. 앱관리자는 자기가 관리하는 앱의 문서(원고의 app 값)와 이 첫 쪽·관리자 안내처럼 공통 문서(audience: admins)만 봅니다. 다른 앱의 문서는 목차에서 빠지고 주소로 열어도 닫혀 있습니다. app 도 audience 도 없는 문서(소스 관리·워크트리·작성 규칙 등)는 전체관리자 전용입니다. 앱관리자 여부는 각 앱의 관리 API가 정본입니다.

편집. 문서를 볼 수 있는 관리자에게 머리글의 편집 단추가 보입니다(공통 문서는 전체관리자만). 저장하면 BioWrit 백엔드가 권한을 다시 확인한 뒤 사이트 저장소 dev 브랜치에 커밋하고, 개발 사이트는 몇 분 뒤 다시 배포됩니다. 운영 사이트에는 다음 릴리즈(dev→main) 때 반영됩니다. 그사이 다른 편집이 먼저 저장됐으면 덮어쓰지 않고 거절합니다.

한계. 정적 호스팅이라 게이트는 화면을 가릴 뿐 HTML 원문 자체를 막지 못합니다. 위키에는 비밀값(키·토큰·비밀번호)을 적지 않습니다 — 편집 서버도 흔한 키 모양은 거절합니다.

문서 관리

문서 작성 규칙을 따릅니다. draft: true인 문서는 목차와 HTML 생성에서 제외됩니다. 위키는 관리자 전용이라 운영 범위 밖 앱의 문서도 싣습니다(tools/check_release.py의 앱 이름 검사에서 위키는 제외). 개발본은 별도 dev 브랜치와 개발 사이트에서 관리합니다.