b3os-release-ops

Files (10)

• SKILL.md
• public-lint-allow.txt
• approver-check.mutants.sh · scripts/
• approver-check.py · scripts/
• approver-check.test.py · scripts/
• preflight-protection.test.sh · scripts/
• public-content-lint.test.ts · scripts/
• public-content-lint.ts · scripts/
• release-preflight.args.test.sh · scripts/
• release-preflight.sh · scripts/

SKILL.md (first lines)

# b3os-release-ops — 공개 배포·머지·핫픽스 게이트

정본 문서: `docs/DEPLOY_MERGE_HOTFIX_WORKFLOW.md`

## 언제 invoke하나

- b3os 공개 `main`에 PR을 merge하기 전.
- live deploy(라이브 배포)하기 전/후.
- hotfix(긴급 수정)를 만들거나 머지할 때.
- force-push/history rewrite/orphan public snapshot 같은 공개 기록 재작성 논의가 있을 때.
- 봇이 “자동 머지해도 되는가?”를 판단해야 할 때.

## 빠른 판정

| 작업 | 봇 자율 가능? | 필수 게이트 |
|---|---:|---|
| 문서 오탈자, 링크, 포맷팅 | 가능 | clean worktree, preflight, 가능하면 리뷰 |
| 테스트만 수정, 제품 동작 불변 | 제한적 가능 | 관련 테스트, preflight, 리뷰 1명 |
| 코드 동작 변경 | 불가 | PR, CI/typecheck, member review, 필요 시 harness |
| DB·권한·보안·시크릿 | 불가 | 팀장 승인, 리뷰, rollback, 감사 로그 |
| live deploy/restart | 불가 | 팀장/운영 승인, dry-run, build, acceptance, rollback |
| branch protection/force-push | 불가 | 팀장 승인, 2명 또는 harness review, backup, audit |

## 표준 실행 절차

### 1. PR merge 전

```bash
# 작업 브랜치에서
skills/b3os-release-ops/scripts/release-preflight.sh --mode merge
bun run typecheck   # 코드 변경일 때
```

확인:

- `git status`가 clean인지.
- 브랜치가 `main`이 아닌지.
- `origin/main..HEAD` commit author·committer email이 GitHub noreply인지.
- GitHub `main` branch protection이 켜져 있는지.
- PR 리뷰 1명 이상을 받았는지.

### 2. clean merge

- 공개 기록에 남길 author가 GD라면 `gd.on` noreply email로 재작성한다.
- merge 수행 계정은 GitHub Settings → Emails에서 “Keep my email addresses private”를 먼저 켠다. GitHub 웹/squash merge commit은 브랜치 commit이 all-noreply여도 머지 수행 계정의 author·committer email을 남길 수 있다.
- rebase/amend/fast-forward merge도 committer email이 로컬 실명 email로 남을 수 있으므로 author와 committer를 모두 확인한다.
- squash/rebase는 PR 범위 안에서만 한다.
- branch protection을 우회하거나 완화하지 않는다.
- merge 후 `git fetch origin main`을 실행하고 `skills/b3os-release-ops/scripts/release-preflight.sh --mode post-merge`로 `origin/main` tip author·committer email이 모두 noreply인지 확인한다.
- post-merge 검증 뒤 `main`을 fast-forward로 맞춘다.

### 3. live deploy

```bash
git fetch origin main
git --no-pager log --oneline HEAD..origin/main        # 반영될 commit 확인(dry-run)
skills/b3os-release-ops/scripts/release-preflight.sh --mode deploy --live-dir "$PWD"

PREV="$(git rev-parse HEAD)"                          # 롤백 지점 — 보고에 남긴다
git reset --hard origin/main
bun install && bun run build
bun run service restart                               # 상시가동 미등록이면 `bun run start` 재기동
```

검증(`/team` 200)이 실패하면 `git reset --hard "$PREV"` → `bun install && bun run build` → 재시작으로 되돌린다. 전체 절차와 인수테스트 기준은 `docs/DEPLOY_MERGE_HOTFIX_WORKFLOW.md`의 “라이브 배포 흐름”이 정본이다.

### 4. 배포 후 인수테스트

- `/team` 200 확인.
- `/team/api/agents` 응답 확인.
- 변경된 사용자 경로를 대표 케이스로 1회 확인.
- 보고에 before/after SHA, 검증, 미검증, rollback을 남긴다.

## Hotfix 모드

1. 증상, 영향, 롤백 기준을 먼저 적는다.
2. `hotfix/<topic>` 브랜치에서 최소 diff로 고친다.
3. 관련 테스트와 실제 재현 경로를 확인한다.
4. member review 1명 이상을 받는다. 공개 장애·보안·데이터 영향이면 harness까지 붙인다.
5. merge 후 즉시 deploy + acceptance를 수행한다.
6. 후속 정리는 별도 작업으로 분리한다.

## Force-push / history rewrite

팀장 승인 없이는 금지다. 승인 후에도 다음을 모두 만족해야 한다.

- 원격 현재 SHA 백업.
- rollback branch/tag 준비.
- secret scan 통과.
- 공개 범위 commit author·committer와 annotated tag tagger email noreply 확인.
- 2명 이상 또는 harness review.
- branch protection 재확인.
- 전/후 SHA와 복구 명령 보고.

## 기계적 가드

`release-preflight.sh`:

```bash
skills/b3os-release-ops/scripts/release-preflight.sh --mode merge
skills/b3os-release-ops/scripts/release-preflight.sh --mode post-merge
skills/b3os-release-ops/scripts/release-preflight.sh --mode deploy --live-dir /path/to/live/repo
```

옵션:

- `--mode merge|deploy|hotfix|force-push|post-merge`
- `--base origin/main`
- `--live-dir <path>`
- `--skip-branch-protection` (GitHub API를 쓸 수 없는 로컬 dry-run 때만)
- `--allow-main` (deploy 모드처럼 main worktree 검사가 필요한 때만)

실패하면 머지/배포하지 말고 원인을 해결한다. `--skip-*` 옵션 사용은 보고에 남긴다.

## 보고 템플릿

```text
files changed:
verified:

From b3rys/b3rys-team-os, Apache-2.0.

More from b3rys/b3rys-team-os