원문: https://github.com/facebook/astryx/wiki/Night-Watch-Vibe-Test-Runner · 번역 기준: 2026-09-03

Assigned to: Cindy's Navi (cixzhang)

Goal: 공정하고 격리된 환경에서 nightly Astryx vibe test suite를 실행한 뒤, 점수 + correctness 실패를 담은 per-night run 이슈 ONE 건을 파일합니다.

Frequency: 하룻밤에 한 번 (~04:00 PDT).

역할 분담 (이것부터 읽으십시오). Runner는 단순하고 신뢰할 수 있는 절반입니다: 테스트를 실행하고, results branch를 push하고, per-night run 이슈를 파일하고, 넘깁니다. Runner는 위키 ledger를 건드리지 않고, API Concerns tracker(#3164)에 게시하지 않습니다. stateful하고 까다로운 모든 작업 — 결과 소비, fix PR 열기, #3164 코멘트, 위키 ledger append, per-night 이슈 close — 은 Vibe Test Debugger의 몫이며, Runner는 마지막 단계로 이를 트리거합니다. 이 분리가 존재하는 이유는, 예전의 "Runner가 위키를 직접 append하는" 흐름이 ledger를 계속 손상시키고(표 안 빈 줄 버그) insight 처리를 분산시켰기 때문입니다. Runner는 기계적으로 유지하십시오.

아키텍처

NAVI (orchestrator)
  │
  ├─ Phase 0: Preflight — verify CLI + environment
  │   pnpm install, pnpm build (packages/cli)
  │   Verify npx astryx --help works in a test project dir
  │
  ├─ Phase 1: Setup + Generate code
  │   setup-nightly.mjs → creates per-agent isolated project dirs
  │   Spawn 40 sub-agents: 10 Astryx + 10 Astryx+TW + 10 baseline + 10 HTML
  │   Each agent works in its own project directory (no cross-contamination)
  │   Output: .tsx/.json in each agent's project dir
  │
  ├─ Phase 1.5: Collect results (collect-results.mjs)
  ├─ Phase 2: Build previews + tsc type-checking (build-previews.ts → build-errors.json)
  ├─ Phase 3: Evaluate (universal-aggregate.ts, universal-compare.ts)
  │
  ├─ Phase 4: Persist + File issue
  │   Deploy report to gh-pages
  │   Commit results to branch: vibe-test/nightly-YYYY-MM-DD (push)
  │   File ONE per-night run issue (label: vibe-test-nightly) with scores + correctness failures
  │   Record the issue number in state (vibeTestRunner.lastIssue)
  │
  ├─ Phase 5: Verify the issue was filed (read it back)
  │
  └─ Phase 6: Hand off to the Debugger (trigger it; safety-net cron backs this up)

Checker Protocol

실행 전에 다음 5가지 invariant를 검증합니다 (internal/vibe-tests/README.md 참조):

  1. 공정한 evaluator — 모든 target에 같은 채점 로직 (target-aware counting은 허용)
  2. 시스템만 달라야 함 — 같은 프롬프트, 시스템별 coaching 규칙 없음
  3. 절대 답을 누출하지 않음 — expectedComponents는 agent 프롬프트에 절대 나타나지 않음
  4. 대표성 있는 환경 — 각 agent는 실제 consumer가 보는 것을 그대로 봄
  5. Context-free agent — 프롬프트마다 fresh spawn, 물려받은 지식 없음

Agent 환경

각 agent는 environments/project-{target}/에서 clone한 격리된 프로젝트 디렉토리를 받습니다:

Target Agent가 보는 것 Discovery 경로
Astryx package.json • node_modules/@astryxdesign/core/ (실제 소스로 symlink) + 동작하는 CLI ls → npx astryx --help 또는 node_modules/@astryxdesign/core/README.md → 컴포넌트 docs
Astryx+TW Astryx와 동일 + Tailwind CSS 사용 가능 같은 discovery + Tailwind utility 클래스
Baseline package.json • components/ui/*.tsx • lib/ • README.md ls → README.md → 실제 shadcn 소스
HTML package.json만 (bare React 프로젝트) 디자인 시스템 없음 — plain HTML + inline CSS

Agent 프롬프트는 이렇게 말합니다: "Your project is at <path>. Explore it to find how to look up component docs." README 경로도, CLI 명령도, 컴포넌트 이름도 주지 않습니다.