Executive Verdict
Fable-ish에서 가져올 것은 검증 습관 하나다. 증거가 나올 때까지 되돌아가 다시 확인하는 습관이다. 말투나 성격(personality)은 가져오지 않는다. 그러니 기존 하네스의 강제 규칙(hard gate, 통과 못 하면 막아 세우는 관문)은 낮추지 않고 그대로 둔다. 대신 여러 작업자를 조율하는 $team 명령이 처리하는 작업 하나하나에 확인 장부(ledger)를 Fable-ish식으로 덧붙인다. 장부에는 그 작업을 어떤 증거로 통과시켰는지 적는다. 그림 가운데 상자가 이 장부를 끼워 넣는 이음새(micro-loop adapter)다. 이음새가 하는 일은 세 가지다. 작업마다 장부를 붙이고, 증거가 어느 단계까지 확인됐는지(proof rung)를 품질 증거에 기록하고, 메워지지 않은 빈 곳은 점수표(scorecard)로 올려 보낸다.
Architecture Comparison
아래 그림은 두 시스템을 나란히 놓은 것이다. 왼쪽은 어디든 들고 다닐 수 있는 도구 꾸러미(Fable-ish package)다. 지시문 한 장과 참고 문서 몇 개, 그리고 실행 환경에 보여줄 설명 파일로 이루어져 있다. 오른쪽은 내 계정 전체(user-scope)와 각 프로젝트에 이미 깔려 있는 통제 층(control plane)이다. 이것이 곧 하네스다. 가운데 있는 이음새(adapter)가 두 쪽을 이어 붙인다. 방법은 $team 명령이 만드는 작업 기록에 새 항목 몇 개를 더하는 것이다. 작업 단위 장부(work_unit_ledger), 상황에 따라 바뀌는 종료 기준(dynamic_exit_criteria), 검증 도구가 없을 때 어떻게 할지 정한 규칙(missing_harness_rule), 검토 관점 대기열(review_lens_queue), 증거가 어느 단까지 확인됐는지 적는 칸(proof_boundary_rung)이 그 항목들이다. 이 항목들은 $team 명령의 단계(Phase 0, 3, 4)로 흘러 들어가 작업 단위 장부와 증거 상향 계약 노릇을 한다.
Capability Matrix
이 부분은 그림보다 표가 더 잘 보여준다. 아래 표는 각 줄에서 네 가지를 나란히 비교한다. 어떤 능력(Capability)인지, 그 능력에 Fable-ish가 무엇을 보태는지(Fable-ish input), 기존 하네스인 Codex Harness가 무엇으로 그걸 이미 받치고 있는지(Codex anchor), 그래서 둘을 어떻게 합칠지(Integration decision)다. 표에 나오는 말 몇 개를 미리 풀어 둔다. 작업 단위(work unit)는 AI에게 시키는 일의 가장 작은 덩어리다. 종료 기준(exit criterion)은 그 덩어리가 끝났다고 볼 조건이다. JSON(기계가 읽기 좋게 이름과 값을 짝지어 적는 데이터 서식)은 표에서 결과를 주고받는 형식이다. 증거의 단(proof boundary rung)은 증거가 얼마나 강한지를 사다리처럼 단계로 나눈 것이다. 하위 작업자(subagent)는 AI 작업자가 일부 일을 떼어 맡기는 더 작은 AI 작업자다. 결정 칸의 "Codex wins"는 기존 하네스 방식을 그대로 쓴다는 뜻이고, "Aligned"는 두 쪽 요구가 이미 같은 방향이라는 뜻이다.
| Capability | Fable-ish input | Codex anchor | Integration decision |
|---|---|---|---|
| Goal intake | Work unit + observable exit criterion. | Normalized goal object in hard JSON. |
Codex wins: ledger goes under the goal object. |
| Completion rule | Proof or explicit blocker only. | Hard validator + QA + audit gates. | Aligned: final report names proof boundary. |
| Dynamic exits | Delta-zero, runtime, deployment boundaries. | Strong gates, weaker per-task labels. | Add proof_boundary_rung in plan + QA evidence. |
| Missing harness | Create the smallest proof tool. | Project validators already exist. | Localize missing_harness_decision per task. |
| Review lenses | Correctness, removed behavior, contracts. | Acceptance QA + subagent routing. | Add queue only for high-risk work units. |
| Subagents | Output is hypothesis. | Bounded ownership, no stale model hardcode. | Codex wins: copy hypothesis-only rule into handoff. |
| Artifact QA | Registry, format, render, consumer proof. | Upgrade audit closes prose-only gap. | Aligned: parser + render smoke required. |
| Loop governance | Raise bar when proof is weak. | Loopy-era eval/report/scorecard. | Bridge levels: proof gaps become scorecard issue IDs. |
Apply To $init-project And $team
실제로 손댈 곳은 네 군데다. 첫째, 새 프로젝트를 준비하는 $init-project 명령이 만들어내는 파일이다. 둘째, $team 명령이 세우는 작업 계획이다. 셋째, 품질 검사 단계(Phase 4)에서 남기는 증거 파일(QA evidence)이다. 넷째, 시스템 점수표(scorecard)로 되돌아가는 피드백이다. 핵심은 이 정보를 그냥 줄글(prose)로 적어두지 않는 것이다. 다음 단계가 기계로 읽고 이어받을 수 있는 데이터 항목으로 넘겨야 한다. 그림 오른쪽의 자가 개선(self-improve) 상자는 점수표의 빈 곳을 받아 다음 프로젝트 실행에 되먹인다. 그림 맨 아래 불변 조건(invariant)이 이것을 세 가지로 못 박는다. 줄글만으로는 통과시키지 않는다. 켜지는지만 보는 스모크 검사(smoke)만으로 화면 작업을 완료 처리하지 않는다. 강제 계약(hard contract)의 수준을 낮추지 않는다.
Recommended Artifact Schema
$team 명령이 쓰는 작업 데이터의 틀(schema)에 Fable-ish 정보를 끼워 넣는다. 그림 왼쪽의 기존 작업 항목(team task)은 지금 모양 그대로 둔다. 그 옆에 새 층으로 작업 단위 장부(work_unit_ledger)를 붙인다. 장부에는 지켜야 할 조건(invariant), 위험(risk), 종료 기준(exit_criterion), 증거를 만드는 명령(proof_command), 검토 관점(review_lenses)이 들어간다. 그리고 품질 증거(QA evidence)와 점수표(scorecard)가 같은 식별 번호(ID)를 공유하게 만든다. 그래야 작업 하나의 증거를 처음부터 끝까지 같은 번호로 추적할 수 있다. 점수표는 열린 빈 곳과 닫힌 빈 곳의 목록, 점수와 등급을 들고 있다가 시스템 전체에 되먹인다. 그림 아래 통과 조건(Pass condition)은 네 가지가 동시에 맞아야 한다. 수용 기준을 확인했고, 증거의 단이 위험 수준과 맞고, 검토에서 나온 지적을 해결했거나 기록했고, 하네스에 빈 곳이 남아 있지 않아야 한다.
Evidence Inventory
이 그림(evidence graph)은 근거의 출처와, 실제로 돌려서 확인한 검증 결과를 한데 묶은 것이다. 이 페이지가 하는 모든 주장은 그림에 적힌 파일들과, 검증 도구를 직접 실행해 나온 결과(validator output)에 뿌리를 둔다. 왼쪽 위는 Fable-ish의 원본 파일이고, 왼쪽 아래는 기존 하네스의 원본 파일이다. 가운데는 이 분석 페이지 자체다. 오른쪽 위는 프로젝트에 실제로 깔려 있는 계약 파일들이다. 오른쪽 아래가 실행 결과다. 강제 계약(hard contract) 검사는 40건 중 40건, 프로젝트 준비 흐름(init workflow) 검사는 157건 중 157건, 사용자 범위 대상(user target) 검사는 156건 중 156건이 통과했다. 업그레이드 감사(upgrade audit) 점수는 100점이다. 전부 실제로 돌려본 기록이다.
Final Assessment
Fable-ish의 진짜 가치는 규율에 있다. AI 작업자(agent)를 더 많이 띄우는 데 있지 않다. 각 작업을 네 조각으로 쪼개는 규율이다. 무슨 일이 있어도 지켜야 할 조건(invariant), 무엇이 위험한지(risk), 어디까지 되면 끝인지(exit criterion), 그리고 그게 됐다는 증거(proof)다. 여기에 하나가 더 붙는다. 그 증거가 진짜 위험을 걸러내지 못하면, 기준을 더 높여 다시 확인하게 만든다. 그림은 이 판단을 세 칸으로 정리했다. 가져올 것(Keep)은 되돌아가 확인하는 반복 습관, 검토 관점의 규율, 검증 도구가 없을 때의 규칙이다. 바꾸지 않을 것(Do Not Replace)은 강제 절차 계약(hard process contract), 품질 검사 관문(QA cycle gate), 업그레이드 감사(upgrade audit)다. 기계가 읽는 작은 검증 반복(micro-loop)으로 들여올 것은 작업 단위 장부, 증거의 단, 검증 도구 부재 판단 세 가지다. 이 셋은 $team 계획과 품질 증거와 점수표의 빈 곳 목록에 저장한다. 완료는 증거가 진짜 위험을 관측했을 때만 인정한다.
결론: 지금 기존 하네스는 이미 강하다. 통과 못 하면 막아 세우는 강제 규칙(hard contract)도, 작업을 시작하기 전에 미리 점검하는 절차($team preflight)도 튼튼하다. 다음 개선은 하나다. Fable-ish의 작은 검증 반복(micro-loop)이 만들어낸 정보를 품질 증거(QA evidence)와 점수표(scorecard) 안으로 빨아들이는 것이다. 그러면 작업 하나하나의 증거가 얼마나 탄탄한지(proof quality)를 사람이 아니라 기계가 곧바로 읽을 수 있게 된다.