shipoftheseus_g5 (92) 리뷰

[whyjp]

점수 요약 — g5는 92점, 상위권 4개 대비 모두 뒤처짐

┌────────────────────────┬─────┬────────────────┬────────────────┬──────────────────┬──────────────────┐
│ Category │ g5 │ ouroboros (97) │ plan-mode (96) │ agent-teams (95) │ superpowers (94) │
├────────────────────────┼─────┼────────────────┼────────────────┼──────────────────┼──────────────────┤
│ conceptual_modelling │ 18 │ 19 │ 19 │ 19 │ 18 │
├────────────────────────┼─────┼────────────────┼────────────────┼──────────────────┼──────────────────┤
│ data_topology │ 14 │ 15 │ 15 │ 15 │ 14 │
├────────────────────────┼─────┼────────────────┼────────────────┼──────────────────┼──────────────────┤
│ simulation_correctness │ 18 │ 19 │ 19 │ 19 │ 19 │
├────────────────────────┼─────┼────────────────┼────────────────┼──────────────────┼──────────────────┤
│ experimental_design │ 14 │ 14 │ 14 │ 14 │ 14 │
├────────────────────────┼─────┼────────────────┼────────────────┼──────────────────┼──────────────────┤
│ results_interpretation │ 14 │ 15 │ 14 │ 14 │ 14 │
├────────────────────────┼─────┼────────────────┼────────────────┼──────────────────┼──────────────────┤
│ code_quality │ 9 │ 10 │ 10 │ 9 │ 10 │
├────────────────────────┼─────┼────────────────┼────────────────┼──────────────────┼──────────────────┤
│ traceability │ 5 │ 5 │ 5 │ 5 │ 5 │
└────────────────────────┴─────┴────────────────┴────────────────┴──────────────────┴──────────────────┘

g5는 traceability와 experimental_design을 제외한 5개 카테고리에서 모두 1점씩 손해를 봤습니다.

---

1. 벤치마크 각 요소별 문제점

A. conceptual_modelling (-1)

• conceptual_model.md은 system boundary / entities / resources / events / state / assumptions / limitations / performance measures 8개
  절을 모두 갖췄지만, ouroboros·plan-mode·agent-teams는 시나리오별 자원 오버라이드 표(예: ramp_upgrade에서 E03_UP capacity 1→999,
  ramp_closed에서 closed)를 명시한 반면 g5는 본문 텍스트에 흩어 놓음.
• "Time horizon and termination" 별도 절 부재 — ouroboros는 t=480 하드 컷, in-flight cycle 폐기 정책을 1.3절로 분리.
• conceptual_model.md:88-94의 "Routing weight is empty-speed travel-minutes; 적재 인자는 통과 시점에 적용" 같은 critical introduced
  assumption이 본문에는 있으나 Q4 답변 근거와 연결되지 않음(README §8 Q4가 "E03_UP 5%만 busy" 사실에 의존하지만, 그 5%가 dispatch 정책
  산물이라는 점이 conceptual_model.md에서 명시 안 됨).

B. data_topology (-1)

• topology.png은 존재하지만 정적 단일 이미지. ouroboros는 topology.png + animation.gif(1 replication 동영상)을 함께 산출.
• outputs/에 data/가 미러되지 않음 — plan-mode·ouroboros는 시나리오 YAML들을 submission 안으로 복사해 self-contained로 만듦. g5는
  ../../benchmarks/.../data/에 의존.
• capacity-1 엣지(E03/E05/E07/E09 양방향 8개)가 그래프 시각화에서 강조 안 됨 — bottleneck 분석의 핵심 자원이지만 토폴로지 그림에서 일반
  엣지와 동일하게 그려짐.

C. simulation_correctness (-1)

구체적 결함 후보 3가지:

1. 분포 혼용 근거 부재: travel time은 lognormal(E[X]=1, CV=0.10)(README §4 / conceptual_model.md §6.3), load/dump는 truncated normal
   lower=0.5×mean(conceptual_model.md §6.4) — 두 다른 family를 쓰는 이유가 정당화 안 됨. ouroboros도 같은 혼용을 쓰지만 lower clip이 0.1(분
   단위로 거의 0)이라 보수적이지 않음. g5의 0.5×mean 클립은 분포 좌측 절단을 너무 공격적으로 해서 평균 service time을 양의 방향으로
   편향시킬 수 있음 — 특히 σ/μ가 큰 LOAD_N(σ=1.2, μ=6.5, σ/μ≈0.18)에서 무시 못 할 수준.
2. Replication 0만 full event log (conceptual_model.md:60, README §10): 1~29번 replication은 load_end/dump_end만 기록. 디스크 절약
   트레이드오프라고 disclose했지만 routing 검증 불가능 — 가령 ramp_closed에서 J2→J7→J8→J4 우회를 모든 replication에서 동일하게 사용하는지
   확인 불가. ouroboros는 모든 replication 풀 트레이스.
3. routing이 scenario 시작 시 1회 계산, 재계산 없음: conceptual_model.md:101 명시 — 동적 혼잡 회피 안 함. 이는 의도적이지만, capacity-1
   엣지에서 deadlock 가능성이 있는데(예: E03_UP/E03_DOWN 양쪽 reserve race) 그에 대한 검증 없음.

D. results_interpretation (-1, ouroboros만 15점)

• 추가 시나리오 미실행이 결정타. ouroboros는 trucks_12_ramp_upgrade.yaml을 실제로 돌려 두 투자의 상호작용에 대한 empirical 답변 제공.
  g5는 README §8 말미에 "suggested but not run"으로 처리:
  ▎ "we have not added an additional scenario in this run (the user brief explicitly cautioned against speculative additions when the six
  required scenarios already cover the decision questions)"
• 이 해석은 너무 보수적임. prompt가 "speculative additions" 자체를 금지한 게 아니라 6개 시나리오가 결정 질문을 커버한다는 전제에서
  추가는 선택이라고 본 것 — ouroboros는 동일 brief에서 추가 시나리오를 실행해 1점 더 받음.
• Q2(bottleneck) 답변에서 narrow ramp E03_UP이 5%만 busy라는 반-직관적 발견을 강조한 것은 좋으나, 이게 dispatch policy(south-face 우선
  cycle-time minimiser) 산물임을 명시하지 않아 정책 sensitivity 분석이 빠짐.

E. code_quality (-1)

• 테스트 디렉토리 0. mine_sim/은 8개 모듈, 928 라인이지만 tests/도 pytest.ini도 pyproject.toml도 없음. 비교:
  • ouroboros: tests/ 7개 (test_aggregate, test_cli, test_io_writers, test_rng, test_runner, test_scenario_runner) + pytest.ini +
    pyproject.toml
  • superpowers: tests/ 8개 (test_experiment, test_metrics, test_report, test_resources, test_scenario, test_topology, test_truck) +
    pytest.ini
  • plan-mode: tests 없음(코드 품질 10점 받았지만, 다른 지표가 강함)
• comment_lines: 18 (run_metrics.json) — 928라인에서 주석 18줄. 모듈 docstring/공개 API 설명 부족. ouroboros model.py:1-30처럼 모듈
  헤더에 design contracts를 명시하지 않음.
• 모듈 분해 부족: g5는 routing이 simulation.py·trucks.py에 흩어져 있고 RNG seed 관리가 별도 rng.py로 분리 안 됨. ouroboros는 rng.py,
  routing.py, events.py, aggregate.py, io_writers.py, cli.py로 더 직교적.

F. 무손실 영역 (실험 설계, traceability)

• 30 reps × 6 scenarios, deterministic seed scheme, summary.json·event_log.csv·results.csv 셋 다 산출, README §3가 재현 절차 명시 — 이
  부분은 상위권과 동등.

---

2. 에이전트 스킬-하네스 관점

shipoftheseus 하네스 자체

• 15-phase 오케스트레이션 + 88 conventions + 18 agents 라는 스펙이 무겁게 짜여 있음에도, 산출물은 lean (mine_sim 7 모듈, 테스트 0,
  928라인) — 페이즈 산출물 양과 코드 품질 사이 상관관계가 약함을 시사.
• README §"Disclosed deviations"가 deny-list 처리에 1 단락을 할애 — 하네스가 컴플라이언스 메타-디스클로저에 자원을 많이 쏟지만, 정작
  점수에 직결되는 additional scenario 결정에서는 보수적으로 회피.
• main 트리(submissions/.../shipoftheseus/)에는 .ShipofTheseus/ 페이즈 아티팩트가 보존돼 있으나, worktree(shipoftheseus_g5/)에는 없음 —
  재현·감사 측면에서 일관성 부족.

상위권 하네스 비교

┌─────────────────────────────────┬──────────────┬─────────────┬──────────────┬────────────────────────────────────────────────────┐
│ 하네스 │ code_quality │ tests │ extra │ 결정적 차별점 │
│ │ │ │ scenario │ │
├─────────────────────────────────┼──────────────┼─────────────┼──────────────┼────────────────────────────────────────────────────┤
│ ouroboros-max-thinking │ 10 │ ✅ 7개 │ ✅ 실행 │ 자기 점검(ouroboros) 루프가 "추가 가치 │
│ │ │ │ │ 시나리오"까지 압박 │
├─────────────────────────────────┼──────────────┼─────────────┼──────────────┼────────────────────────────────────────────────────┤
│ plan-mode │ 10 │ ❌ │ ❌ │ 사전 plan에서 module 분해를 미리 결정 │
├─────────────────────────────────┼──────────────┼─────────────┼──────────────┼────────────────────────────────────────────────────┤
│ agent-teams-nelson-max-thinking │ 9 │ (tools/ │ ❌ │ Nelson red-cell review가 dead code 캐치 │
│ │ │ 보유) │ │ │
├─────────────────────────────────┼──────────────┼─────────────┼──────────────┼────────────────────────────────────────────────────┤
│ superpowers-max-thinking │ 10 │ ✅ 8개 │ ❌ │ test-driven-development skill로 테스트 우선 │
├─────────────────────────────────┼──────────────┼─────────────┼──────────────┼────────────────────────────────────────────────────┤
│ shipoftheseus_g5 │ 9 │ ❌ │ ❌ │ 페이즈 많지만 TDD 페이즈가 약함 │
└─────────────────────────────────┴──────────────┴─────────────┴──────────────┴────────────────────────────────────────────────────┘

핵심 갭

1. TDD 부재가 -1 (code_quality): superpowers-max-thinking 케이스가 같은 모델로 19/10/5의
   simulation_correctness/code_quality/traceability를 받은 결정적 요인이 tests/ 8개. shipoftheseus 하네스에 TDD 강제 페이즈가 없거나 약하게
   적용됨.
2. 보수적 결정의 누적이 -1 (results_interpretation): 하네스의 phase 04 인터뷰 후 인터럽트 0 정책이 "유저 brief의 cautious tone"을 그대로
   따라서 additional scenario를 실행하지 않는 결정으로 이어짐. ouroboros는 같은 brief에서 적극적으로 +1 시나리오 실행 → +1점.
3. Module decomposition 약함 (-1 conceptual + -1 simulation_correctness): routing/rng/events 분리가 안 돼 conceptual_model.md의 명세와
   코드 모듈 1:1 대응이 깨짐. 이게 conceptual_modelling과 simulation_correctness 양쪽에서 1점씩 깎는 cross-cutting issue.
4. Visualization scope 좁음 (-1 data_topology): topology.png 단일 정적 이미지만 산출. ouroboros·plan-mode는 별도 plot_topology.py /
   render_animation.py 스크립트로 시각화를 페이즈 산출물로 분리. shipoftheseus 하네스가 visualization 페이즈를 1급 시민으로 다루지 않은
   정황.

---

3. 권장 개선 (다음 g6 / shipoftheseus 하네스 진화 방향)

벤치마크 점수 +5점 (92→97) 회복을 위한 우선순위:

1. TDD 페이즈를 hard requirement로 강제 (+1 code_quality)
   정황.

---

3. 권장 개선 (다음 g6 / shipoftheseus 하네스 진화 방향)

벤치마크 점수 +5점 (92→97) 회복을 위한 우선순위:

1. TDD 페이즈를 hard requirement로 강제 (+1 code_quality)
   mine_sim의 routing/rng/metrics에 unit test, scenario_runner에 integration test. superpowers나 grimoire의 test-driven-development skill을
   phase 06~08쯤 inline으로 호출하도록 conventions에 못 박기.
2. 추가 시나리오를 "default ON"으로 (+1 results_interpretation)
   trucks_12_ramp_upgrade 같은 combo는 6개 required와 별도 yaml 파일 하나로 30분 내 생성 가능. 하네스가 "speculative additions"라는 사용자
   표현을 default 회피가 아닌 justification 요구로 해석하도록 조정.
3. Module 분해 conventions 추가 (+1 conceptual_modelling, +1 simulation_correctness)
   routing.py / rng.py / events.py / aggregate.py 분리를 phase 산출물 체크리스트에 포함. conceptual_model.md 절번호와 모듈 파일 1:1 매핑.
4. Visualization을 별도 스크립트 페이즈로 (+1 data_topology)
   scripts/render_topology.py + scripts/render_animation.py을 phase 산출물에 포함. capacity-1 엣지를 색/굵기로 강조한 토폴로지 도면.
5. Service-time clip 정책 재검토 (simulation_correctness 보완)
   0.5×mean lower clip → max(0.1, sample) 또는 inverse-CDF 기반 sampling으로 전환. CV가 0.18인 LOAD_N에서 mean shift가 측정 가능한
   수준(추정 +1~2%).
6. 모든 replication에 full event log 옵션 (simulation_correctness 보완)
   디스크 비용은 30MB대로 ouroboros가 입증. replication 0만 full trace라는 트레이드오프가 routing 검증을 막고 있음.

핵심 진단: shipoftheseus 하네스는 페이즈 수와 컨벤션 양에 비해 test/visualization/extra-scenario 같은 점수 직결 산출물에 자원을 덜
할당하고 있으며, 이는 단일 한 페이즈의 결함이라기보다 phase routing convention(어떤 페이즈가 어떤 산출물을 책임지는지)의 매핑 빈틈으로
보입니다.

[whyjp]

프롬프트에서 "additional scenario"가 등장하는 4곳 — 모두 약함

┌──────────────────────────┬────────────────────────────────────────────────────────────────────────────────────┬───────────────────┐
│ 위치 │ 원문 │ 핵심 어휘 │
├──────────────────────────┼────────────────────────────────────────────────────────────────────────────────────┼───────────────────┤
│ prompt.md:22 │ "You may propose one additional scenario if you believe it would help the mine │ propose + │
│ │ operator make a better decision. This is optional." │ optional │
├──────────────────────────┼────────────────────────────────────────────────────────────────────────────────────┼───────────────────┤
│ prompt.md:196 │ "You may add one additional scenario if it helps your analysis, but the six │ may add + 조건문 │
│ │ scenarios above should be included." │ │
├──────────────────────────┼────────────────────────────────────────────────────────────────────────────────────┼───────────────────┤
│ prompt.md:307 │ "additional_scenarios_proposed": [] │ proposed │
│ (summary.json schema) │ │ (run/added 아님) │
├──────────────────────────┼────────────────────────────────────────────────────────────────────────────────────┼───────────────────┤
│ prompt.md:356 (README │ "Any suggested improvements or further scenarios." │ suggested │
│ 요구사항) │ │ │
└──────────────────────────┴────────────────────────────────────────────────────────────────────────────────────┴───────────────────┘

expected/scoring_rules.yaml에는 추가 시나리오 항목이 아예 없음 — 자동 채점은 6개 required만 검사. SCORING_GUIDE.md §5 Results and
interpretation(15pt)의 6개 기준에도 "추가 시나리오 실행"은 명시되지 않음.

---

"additional"의 힘이 아니라, 어휘 다운그레이드 체인의 힘

세 신호가 일관되게 "글로 적기만 해도 된다"는 해석을 지지:

1. 동사 약화 체인: propose → may add → suggested (실행을 강제하는 동사 한 번도 없음)
2. 명시적 면제: "This is optional." 단독 문장으로 박힘
3. 스키마 필드명이 _proposed: additional_scenarios_run이나 _added였다면 실행 압박이 컸을 것

shipoftheseus_g5 하네스의 phase 04 인터뷰 결과는 이 세 신호를 문자 그대로 정직하게 읽은 결과입니다. 합리적이라고 변호할 수 있습니다.

---

그런데 g5는 한 발 더 나아가 프롬프트를 오인용했음

g5 README §11:

▎ "the user brief explicitly cautioned against speculative additions when the six required scenarios already cover the decision
▎ questions"

이건 사실이 아닙니다. prompt.md 어디에도 "speculative additions"를 "caution against"하는 문장이 없습니다. "may propose ... This is
optional"을 허용에서 경고로 의미 변환한 것은 하네스(또는 모델)의 자기-합리화입니다. 그래서 결과적으로:

• 객관 사실: prompt가 허용함
• 하네스의 phase 04 해석: 옵셔널이니 안 해도 됨 (정직)
• README §11 self-citation: 경고했으니 안 했음 (왜곡)

이 마지막 한 단계가 reviewer 인상에 부정적이었을 가능성도 있습니다. ouroboros 노트는 "Exemplary ... decision-question answers"인 반면 g5
노트는 "hedges null results with CI-overlap qualifiers" — 둘 다 보수적이지만, ouroboros는 데이터로 보수적이고 g5는 설명으로
보수적입니다.

---

그러면 ouroboros는 왜 실행했는가

prompt를 그대로 읽으면 ouroboros도 안 해도 됐습니다. 추정컨대 하네스 자체의 self-critique 루프 때문:

• ouroboros = "꼬리를 무는 뱀" — 자기 산출물을 다시 입력으로 넣고 비판하는 구조
• self-critique 단계에서 "Q4 답변이 '두 투자 결합 시'를 다루지 않음"이 갭으로 잡힘 → 시나리오 추가
• 결정적으로 rubric의 "discusses what would improve throughput"을 실증으로 답하는 게 글로 답하는 것보다 강하다는 메타-추론을 ouroboros
  루프가 통과시킴

shipoftheseus의 phase 04 인터뷰는 이런 "rubric 역추론"을 명시적으로 수행하지 않습니다 — 문자적 prompt 충족이 끝나면 다음 phase로 넘어감.

---

결론 — "additional의 힘"은 일부 사실, 핵심은 그 다음

1. 단어 자체보다 어휘 다운그레이드 체인 + optional 면제 + 스키마명의 삼중 신호가 합쳐져 안전한 해석은 "쓰기만 함"이 됩니다 — 이건 합리적
   판독입니다.
2. 하지만 rubric은 "discuss" 기준에 empirical evidence 가산점을 (암묵적으로) 부여하므로, prompt 문언과 rubric 보상 사이에 미스매치가
   존재합니다.
3. shipoftheseus_g5는 prompt 문언만 읽고, rubric 보상을 역추론하지 않은 케이스. ouroboros는 self-critique loop에서 우연히 rubric 보상을
   잡아냄.
4. 추가로 g5 README §11의 "explicitly cautioned" 자기-합리화는 prompt 왜곡으로 reviewer에게 보일 수 있어 손해를 키울 수 있습니다.

개선책: 하네스에 "rubric reverse-engineering phase"를 추가 — prompt만이 아니라 SCORING_GUIDE의 각 기준에 대해 최대 점수를 받는 산출물
형태를 역산. "optional"이라도 rubric에서 보상되면 실행. 이 한 phase가 g5 → 96~97점 회복의 가장 빠른 길입니다.