배경
현재 모든 기능이 GUI로만 노출되어 있어 CI/CD에 박을 수 없다. assetlinks.json 변경 PR이 올라왔을 때 자동 검증할 방법이 없고, 릴리즈 직전 일괄 점검도 수동.
제안
LinkOps의 핵심 검증 로직을 헤드리스로 실행 가능한 CLI로 노출하고, GitHub Action으로 패키징한다.
```bash
linkops verify --domain example.com --package com.foo --fingerprint AB:CD:...
linkops validate-assetlinks --file ./assetlinks.json
linkops batch-test --scenario ./scenarios.json
```
- 기존
domain 레이어(UseCase, Repository)를 그대로 재사용
- 결과는 JSON / JUnit XML / Markdown 형식 출력
- 종료 코드: 0 = pass, 1 = fail (CI 가능)
- GitHub Action: PR diff에서 변경된
assetlinks.json 자동 검증 후 코멘트
왜 우선순위 #3
- 도구가 팀의 워크플로우에 박힘 = 락인 효과
- 한 번 PR에 박히면 떼기 어렵고 도구 가치가 지속됨
- 기존 도메인/데이터 레이어를 거의 그대로 재사용 (UI만 빠진 형태)
성공 기준
범위 외
- npm/brew 배포 (다음 이터레이션)
- Bitrise/CircleCI 액션 (커뮤니티 기여 받기)
배경
현재 모든 기능이 GUI로만 노출되어 있어 CI/CD에 박을 수 없다. assetlinks.json 변경 PR이 올라왔을 때 자동 검증할 방법이 없고, 릴리즈 직전 일괄 점검도 수동.
제안
LinkOps의 핵심 검증 로직을 헤드리스로 실행 가능한 CLI로 노출하고, GitHub Action으로 패키징한다.
```bash
linkops verify --domain example.com --package com.foo --fingerprint AB:CD:...
linkops validate-assetlinks --file ./assetlinks.json
linkops batch-test --scenario ./scenarios.json
```
domain레이어(UseCase, Repository)를 그대로 재사용assetlinks.json자동 검증 후 코멘트왜 우선순위 #3
성공 기준
composeApp:installDist또는 별도:cli모듈로 fat jar / native image 빌드범위 외