feat(skills): fleet-skills intake A2A review gate (skills.skill-intake-review.v1)

[jinon86]

배경

jinwon-int/fleet-skills는 노드가 자동 학습한 스킬의 비공개 검증소다. 현재 intake PR은 사람 게이트(policies/REVIEW.md, approval.json reviewed_by)만 있다. 2026-08-28 소급 감사(ccc-node#1347)에서 스킬 사용량·품질 판단의 체계화가 확정됐고, 사람 게이트 전에 독립 에이전트 심사 게이트를 추가하기로 했다. 이건 nclex 콘텐츠 파이프라인에서 2회 완주한 검증 패턴(RRP-003 #249, PA-006 #251)을 fleet-skills로 확장하는 것이다.

선행 조사(PR-Agent, claude-code-skill-factory#8 required-check 패턴, llm-judge 편향 완화, OpenReview 루브릭 아티팩트 경고) 결론: 자체 A2A 인프라(브로커·keyring·서명 receipt) 재사용이 신뢰·비용 양면에서 우위. 저자 제척이 심사 독립성을 구조적으로 보장한다.

설계

스키마: skills.skill-intake-review.v1

packet (dispatch manifest sourceBundle):

• skillFiles[] — 후보 스킬 파일(경계: 16 files / 64KiB each, 기존 상한과 일치)
• inventorySnapshot[] — fleet-skills approved/ 전체의 {name, audience, description} (저자 노드 아닌 워커가 중복 판정)
• machineGate — 노드 intake 게이트 6종 결과(기계 판독)
• provenance — author_node, intake PR 번호/브랜치, head sha, source_tree_sha256
• rubricVersion — 심사 루브릭 버정("2026-08-28.1")

verdict (워커 결과):

• verdict: approve|revise|reject, findings[], evidence[](기계 재검증 가능 항목: 재현 grep, URL 상태), model, reviewer_node, head_sha

디스패치

• a2a-dispatch-round.mjs 매니페스트, 레인 1개: target = keyring 등록 워커 중 저자 노드 제외 1개
• 브로커 T1(seoseo)/T2(gwakga) 기존 경로, edge secret 취급 규율 동일

워커 절차

• 워커 노드에 skills-intake-reviewer 절차 스킬(루브릭: 비밀/프라이버시, 재고 대비 중복, 주장 검증가능성, 구조 품질, 실용성 — 편향 완화: 단일 후보 심사, 구조 중심 채점, evidence 의무)
• handler 크래시 ≠ 판정: 1회 재시도 → 타 신뢰 워커 재라우팅(nclex 규율 동일)

receipt → 커밋 상태

• PASS 태스크로 receipt 구성(task_id, head_sha, reviewer_node, author_node, result) → intake PR에 게시 → fleet-skills 워크플로가 keyring 검증 후 a2a/receipts 커밋 상태를 exact-head에 투영(nclex a2a-receipts 워크플로 포팅)
• 사람 최종 서명은 유지: A2A PASS가 approval.json reviewed_by를 대체하지 않는다. reject면 게이트 fail-closed(PR 유지, 사람 판단) — auto-close 없음.

단계 계획

• Phase A: 스키마·절차 확정 → 수동 디스패치로 실제 intake PR(fleet-skills R3: public README quickstart security docs and templates #17~feat: import OpenClaw A2A plugin package #20 중 1건)에 첫 라이브 심사 1회
• Phase B: fleet-skills receipts 검증 워크플로 + policies/REVIEW.md 개정
• Phase C: publisher(collect) PR 생성 후 디스패치 자동 연결

작업 항목

• 스키마 문서 + 매니페스트 예제(docs/)
• 워커 절차 스킬 skills-intake-reviewer 초안(trusted 워커 배포는 별도 승인)
• fleet-skills a2a/receipts 워크플로(nclex 포팅) + policies 개정 PR
• Phase A 라이브 1회 — 판정·증거·소요시간 기록
• ccc-node H1: 브로커 구현 파이프라인 서브에이전트화 — explorer→implementer→verifier 계약 (#1346) #1347 크로스링크 및 docs 반영

범위 밖

• 에이전트 auto-close(사람 판단 유지), 졸업 게이트 적용(동일 패턴의 2번째 적용점, 별도 설계), 벡터 임베딩 기반 중복 탐지(재고 ~40개는 컨텍스트 판정로 충분)

[jinon86]

Phase A spec PR: #2008 (docs/skills-intake-review.md — schema, manifest example, worker procedure draft, receipt projection plan).

[jinon86]

Phase A spec merged: 70a20d5 (docs/skills-intake-review.md). Next: Phase B receipts workflow port + REVIEW.md revision.

[jinon86]

Phase A first live run — 2026-08-28 (skills-intake-pr18-r1, PR #18, reviewer: dungae)

• 인프라 종단 검증 성공: 매니페스트 → 브로커 생성(400 소유권 메타데이터 1회 교정 후) → dungae 워커 클레임·처리 → 서명 결과 반환 → 브로커 terminal. 단일 브로커 라운드 소유권 메타데이터(originBrokerId/brokerOfRecordId=gwakga, operatorFacingOwner=local) 규약 확정.
• 발견(예상된 갭): 워커 결과가 evidenceClass: generic_ack — skills-intake-review 인텐트의 워커 측 처리 절차가 미배포되어 루브릭 심사 없이 확인응답만 반환. receipt 불가(검증기가 review PASS validation 요구 — fail-closed 정상 작동).
• 다음: 워커 절차(skills-intake-reviewer, 루브릭 v2026-08-28.2)를 신뢰 워커에 배포(별도 승인) 후 결과보존 재디스패치. nclex 규율상 generic-ack+빈 증거는 재디스패치 허용 케이스.

[jinon86]

Phase A 라이브 6라운드 결과 (r1-r6) — 워커 클레임 라우팅 결함 확정

라운드	target/assignment	결과
r1	dungae	generic_ack
r2	dungae + payload.review.required 계약	generic_ack ("versioned A2A task handler accepted")
r3	daegyo 지정	dungae가 클레임 — generic_ack
r4	+ workspace pin (team2-gwakga/daegyo)	dungae가 클레임 — generic_ack
r5	+ assignedWorkerId=daegyo	dungae가 클레임 — generic_ack
r6	assignedWorkerId=soonwook	dungae가 클레임 — generic_ack

결론: gwakga 브로커에서 dungae의 a2a-hermes-worker가 assignment 필드(targetNodeId/assignedWorkerId)와 무관하게 모든 큐 태스크를 선점하며, 해당 인텐트의 전용 핸들러가 없어 evidenceClass: generic_ack (broker result provenance 서명은 정상 — 검증기는 review PASS validation 부재로 fail-closed 거부, 설계대로 작동).

필요한 운영 조치 (선택): ① dungae 워커 클레임 필터 갱신(빌드 업데이트) ② 진단 기간 dungae 워커 일시 중지(타 워커 클레임 허용) ③ skills-intake-review 전용 핸들러를 dungae 워커에 등록. 증거 원본: gongmyoung ~/.claude/state/a2a-phaseA-evidence/ (r1-r6 broker result + 매니페스트).

[jinon86]

정밀 재현 확정 (r5/r6) — 브로커 create 시 assignedWorkerId 무시 의심 (버그 후보)

재현: 동일 매니페스트에 lane.assignedWorkerId만 변경하며 6회 디스패치(gwakga 브로커 127.0.0.1:18787, broker build 608fdb7, 8커밋 behind main).

• r5: assignedWorkerId: "daegyo" + workspace: {team2-gwakga, daegyo} → 생성 succeeded → 결과 레코드: assignedWorkerId=dungae, claimedBy=dungae, generic_ack
• r6: assignedWorkerId: "soonwook" + workspace pin → 생성 succeeded → 결과 레코드: assigned=dungae, generic_ack
• 608fdb7a의 broker-task-admission은 request.assignedWorkerId를 읽고(85행), claimTask는 assertTaskWorker로 배정 강제(2152행) — 따라서 정상이라면 dungae의 클레임은 policy_denied여야 함.

의심 경로: create 시 workerClassForPolicy(189행) 기반 라우팅이 assignment를 재기록하거나, 대상 필드가 태스크 레코드로 온전히 전달되지 않음. 결과 레코드가 매번 assigned=dungae로 수렴하는 것은 워커 클래스 정책이 dungae(또는 기본 클래스 워커)로 고정하기 때문으로 추정.

증거 원본: gongmyoung ~/.claude/state/a2a-phaseA-evidence/ (r1-r6 매니페스트+결과 전체). 디스패치 로그에는 매 회 created=1.

요청: 브로커 create 경로에서 assignedWorkerId·workspace.nodeId가 태스크 레코드로 전달되는지 확인. 확인되면 skills-intake-review 게이트 Phase A 재개 가능.

[seoseo-ai]

정정 (정밀 조사 완료 — 브로커 버그 아님, 디스패처 고정 task id 재사용이 원인)

직전 코멘트의 "create 시 assignedWorkerId 무시" 가설을 gwakga 브로커(rev 608fdb7a, 도커 a2a-broker-vps7, 영속 상태·감사 로그 직접 조회)로 검증한 결과 기각됐습니다.

1. 브로커에는 r1 태스크 단 1개만 존재 — r2~r6 태스크는 생성된 적 없음

• 감사 로그: skills_intake_review 이벤트는 task.created(2026-08-28T12:42:28.847Z, gongmyoung) → task.claimed(dungae) → task.started → task.succeeded 단 4건, 전부 r1 시각.
• r5/r6 디스패치 시간대(15:58~16:10Z)에 브로커 이벤트 0건 — create도 policy_denied도 없음.
• 라이브 레코드: target=dungae, assignedWorkerId=dungae — r1 생성 당시 값 그대로. daegyo/soonwook 배정 태스크는 존재한 적이 없음.

2. 보존된 "r5/r6 결과" 6개 파일은 전부 r1 사본

• task-result-r1~r6.json 전부 동일 md5(c62bbf73…), 내용 parentRoundId=r1. 매니페스트는 매 라운드 덮어써져 r6 것만 남음.

3. 메커니즘 — createTask 멱등 반환

• 디스패처가 매 라운드 고정 id skills_intake_review(=매니페스트 lane.id)로 POST. 브로커 createTask는 기존 id 요청 시 기존 레코드를 그대로 반환(감사 이벤트·에러 없음 — 608fdb7a와 main 674fc75b 동일, 8커밋 차이는 docs/ListTasks뿐).
• 디스패처는 이 응답을 "created=1"로 오계산했고, 결과 페치도 매번 동일 레코드 → 6개 동일 파일. assignment 필드는 어떤 태스크 레코드에도 도달한 적 없음.

4. 배정 강제(assertTaskWorker)는 정상 작동 중

• 같은 브로커의 nclex 태스크들(daegyo→high_risk_safety, dungae→content_clinical, gongmyoung→evidence_adversarial)에서 각 워커가 자기 배정 태스크만 클레임 — 실전 실증. dungae가 클레임 가능했던 이유는 태스크가 애초 target=dungae(r1)였기 때문.

확인된 운영 결함 (별도 조치)

• ① 디스패처: 라운드별 유니크 task id 미사용(관례상 -rN-<ts> 접미사 필요) + 멱등 반환을 신규 생성으로 오인.
• ② 브로커 관측성 갭: 멱등 create가 신규생성/기존반환을 구분 불가(플래그·감사 없음). 라이브 모드 경로는 중복 id에 invalid_transition을 던져 이원화 — 별도 이슈로 보고.
• ③ 증거수집: 매니페스트 덮어쓰기 + 결과 동일 사본 6개 저장.
• ④ r6 매니페스트 자체 불일치(target.id=daegyo vs workspace.nodeId=soonwook) — 그대로 POST 시 assertTaskPayload가 policy_denied 예정.

다음: 유니크 task id로 daegyo/soonwook 배정 재검증 디스패치를 실행하고 결과를 이어서 코멘트합니다. Phase A 게이트는 브로커 수정 대기 없이 재개 가능합니다.

[seoseo-ai]

재검증 완료 — assignment 라우팅 정상 입증 (유니크 task id, 브로커 608fdb7a)

위 정정 코멘트대로 유니크 id + 일관된 workspace + assignedWorkerId를 명시해 2건 재디스패치했습니다. 결과:

task id (gwakga 브로커)	생성 레코드 assignedWorkerId	클레임 워커	결과
skills_intake_review-verify-daegyo-20260828T170820Z	daegyo	daegyo (17:08:29Z)	succeeded, generic_ack
skills_intake_review-verify-soonwook-20260828T170820Z	soonwook	soonwook (17:08:26Z)	succeeded, generic_ack

• 감사 로그: 각 태스크마다 task.created → task.claimed(배정 워커) → task.started → task.succeeded 독립 기록. r2~r6 때와 달리 매 create가 실제 태스크로 기록됨.
• 결과 원본 md5 3종 전부 distinct: daegyo d18a1202… / soonwook 7ba79a22… / 구 r1 사본 c62bbf73…. 증거는 gongmyoung ~/.claude/state/a2a-phaseA-evidence/verify-* 에 라운드별 파일로 보존.
• 검증 payload는 r6 매니페스트에서 review 계약 키만 제외했습니다(완료 시 fail-closed review PASS 검증을 유발하므로 — 라우팅 검증과 무관). generic_ack는 기존에 확인된 워커 측 인텐트 핸들러 미배포 갭 그대로.

결론: 브로커 create 경로의 assignedWorkerId 저장과 claim 배정 강제는 모두 정상. Phase A 게이트의 잔여 작업(워커 절차 배포 → 루브릭 심사 → receipt)은 본 검증에서 준비된 디스패치 방식(유니크 id + 배정 일관성)으로 진행하면 됩니다. 관측성 갭은 #2010으로 추적.

[jinon86]

r8 (풀 모드) 결과 — 근본 원인 최종 특정: 워커 실행 핸들러 미구성

절차(skills-intake-reviewer, 루브릭 v.2)를 T2 풀 3노드(dungae/daegyo/soonwook piri 스킬 디렉토리)에 배포 후 미배정 태스크 디스패치 → dungae 클레임 → 결과 완전히 비어 있음(output={}, validations=null, summary 없음). 실패 사유 동일(review evidence missing).

원인: dungae(a2a-hermes-worker, /opt/a2a-broker-worker)의 HANDLER_COMMAND 미설정 — 워커가 builtin(noop/echo급) 폴백으로 동작해 실행 주체가 없음. soonwook도 동일. 즉 절차 유무 이전에 워커가 태스크를 실행할 런타임 핸들러 자체가 없는 것이 최종 원인.

필요한 운영 구성: 워커 env의 HANDLER_COMMAND(± HANDLER_ARGS_JSON/CWD/TIMEOUT)에 skills-intake-review 패킷을 로컬 LLM 런타임으로 심사해 TaskResult JSON(validations[kind=review] 포함)을 stdout으로 출력하는 핸들러를 지정. 런타임 선정(piri/claude/codex)과 자원 비용은 운영자 결정 사항 — 절차 스킬은 3노드 배포 완료 상태.

[jinon86]

r11 최종 원인 특정 — 워커 핸들러 미등록 (운영 인프라 결정 사항)

dungae 워커(/opt/a2a-broker-worker/dist/worker.js)는 intent-router를 사용하지 않는 bare 등록(A2ABrokerWorker + builtin task handler)이며 HANDLER_COMMAND 미설정 → skills-intake-review 인텐트가 builtin echo 폴백으로 처리되어 generic_ack. payload.review.required 계약이 result 검증에서 fail-closed로 태스크를 실패시킨 것은 정상 동작.

즉 브로커 버그가 아니라 dungae 워커 배포에 실행 핸들러가 없는 인프라 상태. 해결은 운영자 구성: (a) hermes 풀 워커 런타임 배포(nclex sogyo 선례와 동일), 또는 (b) HANDLER_COMMAND에 심사 핸들러 스크립트 등록(스크립트 초안은 gongmyoung이 작성 완료 — 패킷→claude CLI 루브릭 심사→TaskResult JSON 출력, 9경로 테스트 통과 예정).

Phase A는 여기까지가 라이브 범위. 이후 핸들러 구성 → 재디스패치 → receipt → Phase B로 이어진다.