414960701/harness-distiller

Harness Distiller（Agent Harness 蒸馏器）

공개 증거를 실행 가능하고, 검증 가능하며, 업그레이드 가능한 Agent Harness로 증류합니다. 제품명을 행동과 능력 레시피로 간주하며, 브랜드, 독점 프롬프트, 보호된 자료 또는 검증 불가능한 내부 구현을 복사하지 않습니다.

반드시 준수할 사항

1. code, official-doc, protocol, behavior, inference를 구분합니다. 클로즈드 소스 제품 추론을 소스 코드 사실로 작성해서는 안 됩니다.
2. 네 가지 성숙도 레벨은 동일한 프로토콜, 상태 모델 및 모듈 경계를 공유합니다. 업그레이드는 기능과 최적화만 추가하며, 상호 호환되지 않는 네 가지 엔지니어링 세트를 생성하지 않습니다.
3. 먼저 수직 슬라이스를 완성합니다: 모델 → Agent loop → 하나의 읽기 도구 → 권한 → 실행 → 이벤트 → 상태 → 인터페이스.
4. Runtime은 headless 상태를 유지합니다. CLI, TUI, IDE, Desktop, Web은 버전이 지정된 command/event 프로토콜을 통해서만 상호 작용합니다.
5. Approval policy와 sandbox enforcement를 분리합니다. 사용자 승인이 OS, 컨테이너, 경로 또는 네트워크 강제 경계를 대체할 수 없습니다.
6. 각 "구현 완료" 항목에는 코드 위치가 있어야 합니다. 각 "검증 완료" 항목에는 실행 가능한 테스트 또는 반복 가능한 행동 증거가 있어야 합니다.
7. 모델이 셸을 호출할 수 있다는 것을 "완전한 Harness"로 간주하지 마십시오. 취소, 실패, 복구, 영속성, 권한 및 인터페이스 상태 재구축을 반드시 구현해야 합니다.

필요에 따라 읽기

• 제품 선택 및 디렉토리 완전성 확인: references/catalog.md를 읽으십시오.
• 레벨 선택 또는 레벨 간 업그레이드: references/levels.md를 읽으십시오.
• 각 capability를 언제 verified로 표시할지 판단: references/capabilities.md를 읽으십시오.
• 증거 신뢰성 판단: references/evidence.md 및 references/source-registry.md를 읽으십시오.
• 공유 경계 이해: references/architecture.md를 읽으십시오.
• 코드 작성을 시작하기 전에: 반드시 references/implementation/index.md를 읽고, 그 라우팅에 따라 구현 명세를 로드하십시오.
• 공유 능력 선택: references/knowledge/index.md를 읽고, 청사진이 선택한 지식 모듈만 로드하십시오.
• 특정 제품 포크: references/products/<product>/index.md를 읽고, 인덱스에 지정된 순서대로 해당 제품의 13개 dossier를 로드하십시오.
• 새 프로젝트 생성: references/workflows/build.md를 읽으십시오.
• 기존 프로젝트 업그레이드: references/workflows/upgrade.md를 읽으십시오.
• 프로젝트 검수: references/workflows/validate.md를 읽으십시오.

요청 분석

사용자 요청 및 대상 저장소에서 다음을 구문 분석합니다:

• recipe: 제품, hybrid 또는 custom
• level: runnable, usable, productive 또는 polished
• surfaces: cli, tui, ide, desktop, web, sdk, headless
• execution: local, container, remote 또는 조합
• stack: 가능하면 대상 저장소의 기존 스택을 유지합니다. 새 프로젝트는 제품 표면 및 보안 요구 사항에 따라 선택합니다.
• providers: 모델 제공자, 로컬 모델 및 능력 저하 요구 사항
• security: 개인, 팀 또는 기업 위협 모델
• distribution: 소스 코드, 패키지, 확장, 데스크탑 앱 또는 호스팅 서비스

사용자가 "Codex/Claude Code/QoderWork 같은 제품을 만들어 주세요"라고만 말할 경우, 해당 recipe, usable 레벨, 제품의 주요 표면 + headless를 기본값으로 선택하고, 해당 가정을 결정 기록에 기록합니다.

다른 선택 사항이 없을 때는 다음 대체 가능한 기본값을 사용합니다: execution=local, security=personal, distribution=source. Codex-like는 기본적으로 Rust + headless/TUI, Claude-Code-like는 기본적으로 TypeScript + headless/CLI, QoderWork-like는 기본적으로 TypeScript + Tauri/Rust executor + headless/Desktop, Aider-like는 기본적으로 Python + headless/CLI, OpenCode는 기본적으로 TypeScript/Bun + headless/TUI, OpenHands는 기본적으로 Python + TypeScript/React + headless/Web/SDK, AgentScope, LangGraph 및 Deep Agents는 기본적으로 Python + headless/SDK입니다. Provider가 지정되지 않은 경우, 먼저 provider-neutral contract, 결정론적 스크립트 fixture 및 OpenAI 호환 어댑터 인터페이스를 구현하고, 유료 서비스를 임의로 바인딩하지 않습니다. 실제 통합 테스트 전에 사용자에게 provider 구성을 요청합니다.

생성 프로세스

1. 저장소, 기술 스택, 기존 명령어, 더티 변경 사항 및 사용 가능한 실행 환경을 확인합니다.
2. references/catalog.md에서 제품이 구현 레벨인지 확인합니다. 계획되었지만 13개 dossier가 완료되지 않은 recipe는 제품 포크를 생성해서는 안 되며, 먼저 dossier를 보완하거나 명시적으로 hybrid/custom으로 전환합니다. 그런 다음 scripts/new_blueprint.py를 실행하여 .harness-distill/blueprint.yaml을 생성합니다.
3. 제품 index.md, product-contract.md, recipe.md, acceptance-tests.md를 읽습니다.
4. recipe에 따라 구현 명세 및 공유 지식 문서를 로드하고, capability 종속성 폐쇄(closure)를 설정합니다.
5. .harness-distill/evidence.md를 작성하여 주장, URL, 날짜, 버전/커밋, 증거 유형 및 신뢰도를 기록합니다.
6. .harness-distill/decisions.md를 작성하여 아키텍처 선택, 클로즈드 소스 추론, 비목표, 위험 및 롤백 지점을 기록합니다.
7. 먼저 프로토콜, 상태 스켈레톤 및 실행 가능한 수직 슬라이스를 구현하고, 해당 이벤트 트레이스를 저장하고 재생합니다.
8. schema → protocol → runtime → executor/policy → surface → migration 순서로 기능을 보완합니다.
9. 동시에 contract, scenario, security, recovery, migration 및 제품 블랙박스 테스트를 추가합니다.
10. scripts/validate_blueprint.py, 대상 저장소 검사 및 제품 acceptance-tests.md를 실행합니다.
11. 구현 위치와 테스트 증거가 있는 capability만 verified로 표시합니다.

산출물 최소 계약

대상 프로젝트는 다음과 동등한 경계를 포함해야 합니다:

.harness-distill/
  blueprint.yaml       # 선택, 레벨, 능력, 상태 및 계약 버전
  evidence.md          # 공개 증거 및 추론 경계
  decisions.md         # 아키텍처 결정, 비목표, 위험 및 마이그레이션
src/
  protocol/            # command/event/error/schema/capability negotiation
  runtime/             # turn 상태 머신, 취소, 재시도, 예산, steering
  model/               # provider 어댑터 및 능력 협상
  context/             # 명령어, 검색, 메모리, 예산, 압축, 캐시
  tools/               # schema, registry, router, lifecycle, artifact
  policy/              # allow/deny/ask/amend 및 승인 범위
  execution/           # workspace, 파일, shell, patch, 네트워크, sandbox
  state/               # thread/turn/item/event/checkpoint/migration
  surfaces/            # CLI/TUI/IDE/Desktop/Web 어댑터
tests/
  contracts/           # 프로토콜, provider, 도구 및 저장소 계약
  scenarios/           # 실제 작업 폐쇄 루프
  security/            # 경계 침범, 인젝션, 비밀, 네트워크 및 탈출
  recovery/            # 충돌, 중복 전달, 연결 끊김 및 마이그레이션

언어 관례에 따라 이름을 변경할 수 있지만, 정책과 강제 실행, 도메인 상태와 UI 투영, 모델 히스토리와 영구 사실 간의 경계를 병합해서는 안 됩니다.

완전성 게이트

선택한 레벨의 완전한 Harness로 간주되려면 다음 모든 조건을 충족해야 합니다:

• blueprint, 제품 계약 및 구현 위치가 일치해야 합니다.
• runnable의 thread/turn/item/event trace는 영속화 및 재생 가능해야 합니다. usable부터는 페이징 및 프로세스 재시작 복구를 지원해야 합니다. polished는 크로스 버전 마이그레이션을 추가로 요구합니다.
• tool call/result는 원자적으로 쌍을 이루어야 하며, 취소, 타임아웃 및 지연된 결과에 대한 의미가 명확해야 합니다.
• 컨텍스트 압축을 선택한 경우, tool call 원자성, 명령어 계층 구조 및 감사 범위를 손상시켜서는 안 됩니다.
• 제한된 동작은 먼저 정책에 의해 결정된 후, 실제 실행 경계에 의해 강제되어야 합니다.
• UI는 snapshot + event를 사용하여 재구성 가능해야 하며, runtime 메모리 객체에 의존해서는 안 됩니다.
• usable 이상의 충돌 복구는 되돌릴 수 없는 부작용을 반복해서는 안 됩니다.
• 제품 acceptance-tests.md의 현재 레벨 시나리오를 통과해야 합니다.
• 제공 노트는 지원되지 않는 동작, 증거 격차 및 직접 업그레이드 경로를 명시해야 합니다.

레벨 간 업그레이드

임의의 낮은 레벨에서 높은 레벨로 직접 업그레이드할 때:

1. 현재 blueprint, 프로토콜 및 데이터베이스 스키마를 검증합니다.
2. capability delta를 계산하고 중간 종속성을 펼칩니다.
3. 먼저 스키마를 마이그레이션한 다음, 프로토콜, runtime, executor 및 인터페이스를 확장합니다.
4. 이전 구성 및 이전 이벤트를 적어도 하나의 호환 가능한 마이그레이션 경계로 유지합니다.
5. 되돌릴 수 없는 외부 동작에 대해 checkpoint, idempotency key 또는 사람의 확인을 설정합니다.
6. 모든 낮은 레벨 회귀 테스트와 새 레벨 승인 테스트를 실행합니다.
7. 테스트 통과 후 capability 상태를 업데이트합니다.