autoresearch artifact · architecture diagram

검증 도구 Fable-ish를 Codex Harness 위에 얹는 법

결론부터 말하면, 새 검증 도구는 기존 시스템을 갈아치우는 게 아니라 그 위에 한 층 덧대는 방식으로 합치는 게 맞다. 여기서 새 도구의 이름이 Fable-ish다. Fable-ish는 AI에게 일을 작은 덩어리로 쪼개게 하고, 덩어리마다 "정말로 됐다"는 증거가 나올 때까지 다시 확인시키는 지시 묶음(이런 지시 묶음을 skill이라 부른다)이다. 반대편의 기존 시스템은 이미 탄탄하다. 새 프로젝트를 자동으로 준비해주는 명령($init-project), 조건을 통과하지 못하면 작업을 막아 세우는 강제 규칙(hard gate), 여러 AI 작업자를 한 번에 부리는 명령($team), 품질을 되풀이해 점검하는 절차(QA), 스스로를 되짚어 감사하는 기록(loopy-era)까지 갖췄다. 이렇게 AI가 "다 했다"고 얼버무리지 못하도록 증거를 강제하는 감시 장치 전체를 하네스(harness)라 부른다. 이 글은 둘 중 하나를 버리는 비교가 아니라, 새 도구를 기존 하네스 위에 어떻게 얹을지를 다룬다.

1
portable micro-loop
14
hard contract IDs
21
hard process edges
100
upgrade audit score
01 · decision

Executive Verdict

Fable-ish에서 중요한 건 말투나 성격(personality)이 아니라, 증거가 나올 때까지 되돌아가 확인하는 검증 습관이다. 그러니 기존 하네스의 강제 규칙(hard gate, 통과 못 하면 막아 세우는 관문)은 낮추지 않고 그대로 둔다. 대신 여러 작업자를 조율하는 $team 명령이 처리하는 작업 하나하나에, 무엇을 어떤 증거로 통과시켰는지 적는 확인 장부(ledger)를 Fable-ish식으로 덧붙인다.

Fable-ish work unit framing dynamic exit criteria missing harness synthesis per-task discipline Integration Decision additive layer, not replacement attach ledger to each team task record proof rung in QA evidence escalate gaps to scorecard micro-loop adapter Codex Harness normalized goal intake hard process contract team preflight and QA gates runtime governance Correct upgrade: machine-readable per-work-unit evidence inside existing hard gates
02 · system architecture

Architecture Comparison

아래 그림은 두 시스템을 나란히 놓은 것이다. 왼쪽은 어디든 들고 다닐 수 있는 도구 꾸러미(Fable-ish)다. 오른쪽은 내 계정 전체와 각 프로젝트에 이미 깔려 있는 통제 층(control plane), 즉 하네스다. 가운데 있는 이음새(adapter)가, $team 명령이 만드는 작업 기록에 새 항목 몇 개를 더해 두 쪽을 이어 붙인다.

Fable-ish package portable per-task loop harness SKILL.md prime directive, loop stop at observed proof references/*.md loop harness dynamic exit criteria verification ladder review and subagents agents/openai.yaml display metadata default prompt surface Adapter micro-loop fields work_unit_ledger dynamic_exit_criteria missing_harness_rule review_lens_queue proof_boundary_rung recommended, not replacement Codex user-scope harness project governance and hard runtime gates AGENTS.md operating contract $init-project normalized goal, bridge hard process contract hard contracts and edges $team runtime preflight, acceptance, QA loopy-era evidence eval, report, audit Binding: Fable-ish feeds `$team` Phase 0/3/4 as work-unit ledger and proof escalation contract.
03 · capability matrix

Capability Matrix

이 부분은 그림보다 표가 더 잘 보여준다. 아래 표는 각 줄에서 네 가지를 나란히 비교한다. 어떤 능력(Capability)인지, 그 능력에 Fable-ish가 무엇을 보태는지(Fable-ish input), 기존 시스템 Codex가 무엇으로 그걸 이미 받치고 있는지(Codex anchor), 그래서 둘을 어떻게 합칠지(Integration decision)다.

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.
04 · init-project to team

Apply To `$init-project` And `$team`

실제로 손댈 곳은 네 군데다. 새 프로젝트를 준비하는 $init-project가 만들어내는 파일, $team이 세우는 작업 계획, 품질 검사 4단계(Phase 4)에서 남기는 증거 파일(QA evidence), 그리고 시스템 점수표(scorecard)로 되돌아가는 피드백이다. 핵심은 이 정보를 그냥 줄글(prose)로 적어두지 않는 것이다. 다음 단계가 기계로 읽고 이어받을 수 있는 데이터 항목으로 넘겨야 한다.

$init-project generate scaffold goal object hard contract existing bridge work_unit_ledger invariant risk proof command new field $team plan task spec acceptance exit criterion Phase 0/1 QA evidence acceptance_verified proof_boundary_rung proof_observed Phase 4 scorecard gap open_gaps[] closed_gaps[] system feedback self-improve soft to hard scope decision promotion path next project run fresh context persistent state closed loop Invariant: no prose-only pass, no smoke-only UI completion, no hard-contract downgrade.
05 · artifact schema

Recommended Artifact Schema

$team이 쓰는 작업 데이터의 틀에 Fable-ish 정보를 끼워 넣는다. 그리고 품질 증거(QA evidence)와 점수표(scorecard)가 같은 식별 번호(ID)를 공유하게 만든다. 그래야 작업 하나의 증거를 처음부터 끝까지 같은 번호로 추적할 수 있다.

team task id spec acceptance existing shape work_unit_ledger invariant risk exit_criterion proof_command review_lenses new layer qa evidence acceptance_verified[] proof_boundary_rung proof_observed missing_harness_decision candidate_findings[] hard QA observation loopy-era scorecard open_gaps[] closed_gaps[] score, level system feedback Pass condition acceptance verified + proof rung matches risk + review findings resolved or recorded + open harness gaps empty
06 · evidence graph

Evidence Inventory

이 그림은 근거의 출처와, 실제로 돌려서 확인한 검증 결과를 한데 묶은 것이다. 이 페이지가 하는 모든 주장은 그림에 적힌 파일들과, 검증 도구를 직접 실행해 나온 결과(validator output)에 뿌리를 둔다. 즉 추측이 아니라 돌려본 기록으로 뒷받침한다.

Fable-ish source /Downloads/fable-ish/SKILL.md references/*.md agents/openai.yaml Harness source ~/.codex/harness/* init-project/SKILL.md team/SKILL.md Analysis artifact fable-ish-harness-comparison.html inline SVG diagrams parser validation Project runtime hard-process-contract.json team-handoff.json harness-upgrade-audit-latest.json Observed validation hard contract: 40/40 init workflow: 157/157 user target: 156/156 upgrade audit: score 100
07 · final assessment

Final Assessment

Fable-ish의 진짜 가치는 AI 작업자(agent)를 더 많이 띄우는 데 있지 않다. 각 작업을 네 조각으로 쪼개는 규율에 있다. 무슨 일이 있어도 지켜야 할 조건(invariant), 무엇이 위험한지(risk), 어디까지 되면 끝인지(exit criterion), 그리고 그게 됐다는 증거(proof)다. 그리고 그 증거가 진짜 위험을 걸러내지 못하면, 기준을 더 높여 다시 확인하게 만드는 규율이다.

Keep dynamic loop habit review lens discipline missing harness rule Do Not Replace hard process contract QA cycle gate upgrade audit Adopt As Machine-Readable Micro-Loop work_unit_ledger + proof_boundary_rung + missing_harness_decision stored in team plan, QA evidence, and scorecard gap inventory completion only when evidence observes the real risk

결론: 지금 기존 하네스는 이미 강하다. 통과 못 하면 막아 세우는 강제 규칙(hard contract)도, 작업을 시작하기 전에 미리 점검하는 절차($team preflight)도 튼튼하다. 다음 개선은 하나다. Fable-ish의 작은 검증 반복(micro-loop)이 만들어낸 정보를 품질 증거(QA evidence)와 점수표(scorecard) 안으로 빨아들이는 것이다. 그러면 작업 하나하나의 증거가 얼마나 탄탄한지(proof quality)를 사람이 아니라 기계가 곧바로 읽을 수 있게 된다.