implementation-lane readiness: 노드별 implementationCapability 프로파일 발행 + fleet 모델 티어 정책

[jinon86]

Warning

이 본문의 최초 매트릭스는 2026-07-26 실측으로 정정됐고, 갱신되지 않은 채 오라우팅을 유발했습니다.
2026-08-03 코멘트 기록: "이 이슈 본문의 매트릭스만 보고 워커를 골랐다가 두 번 틀렸습니다."
아래 정정된 매트릭스를 사용하십시오. 최초 표는 이력 보존을 위해 접어 두었습니다.

정정된 매트릭스 (2026-07-26 실측 기준, T2 브로커 노드 직접 SSH 프로브 + Family Wiki 노드 페이지)

owner-facing bridge 의 provider 와 A2A worker 의 provider 는 별개 경로입니다. 최초 표가 이 둘을 섞은 것이 오진의 원인이었습니다.

worker	claude CLI	A2A worker provider	owner-facing bridge	implementation lane
dungae	2.1.210, native OAuth	Anthropic native	—	full handler
gongyung	2.1.210, native	Anthropic native	—	native Termux worker, canPatchWorkspace=true, single-shot
soonwook	2.1.210	Anthropic native (A2A_WORKER_BRIDGE_ADAPTER=claude-code, A2A_CLAUDE_CODE_RUNTIME_MODEL=claude-sonnet-5, ANTHROPIC_BASE_URL 미설정, env 내 kimi 0건)	Kimi Code k3[1m]	patch runner
jingun	none (intentional)	Codex gpt-5.6-sol	—	codex-only
daegyo	masked (exit 125, 2026-07-15)	Codex gpt-5.6-sol	—	analyze-only, canPatchWorkspace=false
gongmyoung	none	—	—	not implementation-capable

정정 근거: Family Wiki [ND-1321] (2026-07-26 실측), 본 이슈 2026-07-26 / 2026-08-03 코멘트.

Proposal 진행 상태 (2026-08-07 확인)

• 1. worker capability/model matrix — 구현 완료. docs/implementation-lane-readiness.md의 implementationCapability 프로파일(capable/runtime/providerId/modelTier/availability/lastVerifiedAt/evidenceId)이 등록·하트비트 capabilities 페이로드로 전달되고, WORKER_IMPLEMENTATION_* / A2A_ 별칭 환경변수로 선언합니다. 코드: packages/broker/src/worker.ts (WORKER_IMPLEMENTATION_MODEL_TIER, WORKER_CAN_PATCH_WORKSPACE). 미선언 시 legacy 경로로 구현 작업에서 제외됩니다. 관련 후속: [P0][A2AD] 최적화 감사 후속 — invalid JSON 회귀·false readiness·antithesis 증거 손실 #1725 발견 2 라우팅분(PR feat(worker): gate canAnalyze on registration-time handler artifact probe (#1597) #1735, 3952a35).
• 2. fleet 모델 티어 정책 — 미결.
• 3. T2 추가 Claude-native 워커 확보 (또는 dungae 한정 명문화) — 미결.

최초 본문 (2026-07-22) — 매트릭스가 부정확합니다. 이력 보존용

Found while routing real implementation work through T2 (2026-07-22 benchmark pilot + wiki-agent issue lanes):

worker	runtime	implementation-capable today
dungae	Claude CLI 2.1.210, native Anthropic OAuth, model opus-4-x[1m]	yes (only one)
jingun	Codex node (/root/.codex), no Claude auth	codex-only
soonwook	Claude Code but Kimi K3 backend (api.kimi.com/coding)	model-confounded
daegyo	Android/Termux mobile	analyze-only per policy
gongmyoung	no claude CLI; GitHub write disabled	no

Consequences observed:

• All real T2 implementation lanes serialized onto dungae (single point of contention and failure).
• Model tier is heterogeneous across workers, so any cross-worker quality comparison (or quorum) mixes model effects with worker/pipeline effects.
• The broker cannot express these capabilities: intent: implementation tasks were auto-acked by a generic handler regardless of worker capability (worker: generic implementation-intent tasks are auto-acked as succeeded with zero work (false success) #1593).

Proposal:

1. Add a worker capability/model matrix (registered at heartbeat or in broker policy) — provider, model tier, implementation-capable flag — so dispatch can route or reject by capability instead of false-success acking.
2. Define a fleet policy for implementation-lane model tier (pin or record) so evidence quality is interpretable.
3. Track bringing at least one more T2 worker to Claude-native implementation capability (or formally scope T2 implementation to dungae + document).

Refs: #1593, #1543, Family Wiki LOG-20260722-gwakga-2.

[jinon86]

Live re-check on 2026-07-26 (direct SSH probes from the T2 broker node, plus Family Wiki node pages). Several rows in the original table are stale or conflated, and the framing of the fix changed as a result.

Corrected matrix

worker	claude CLI (login shell)	provider	implementation lane
dungae	2.1.210, native OAuth, no API key	Anthropic native	full handler
gongyung	2.1.210, native	Anthropic native	native Termux worker, canPatchWorkspace=true, single-shot
soonwook	2.1.210	login shell shows a native base URL; worker unit Environment is empty (see caveat)	patch runner
jingun	none (intentional)	Codex gpt-5.6-sol	codex-only
daegyo	masked (exit 125, 2026-07-15)	Codex gpt-5.6-sol	analyze-only, canPatchWorkspace=false
gongmyoung	none	—	not implementation-capable

Corrections

1. gongmyoung and gongyung are two different nodes. They are separate SSH hosts. The original row is accurate for gongmyoung, but gongyung — which was not in the table — is a live native Termux A2A worker with Claude Code 2.1.210 on an Anthropic-native route, and it already declares:

   {"canAnalyze":true,"canBackfill":false,"canPatchWorkspace":true,
    "canPromoteLive":false,"workspaceIds":["gongyung-claude-code"],
    "environments":["research","staging"]}

2. "GitHub write disabled" no longer applies to gongyung. Its gh CLI is authenticated as seoseo-ai, and seoseo-ai holds write on this repository (push: true). The PR path is open.

3. "only one implementation-capable worker" is stale. soonwook (patch runner) and gongyung (canPatchWorkspace=true) both have patch lanes today.

4. daegyo is analyze-only for a different reason than "mobile policy". Since the 2026-07-15 Codex cutover its Claude entrypoint is masked and the worker config sets canPatchWorkspace=false. Worth noting the analysis bridge was last verified 2026-07-13, two days before the mask — its current health is unverified.

5. dungae model tier is unverified. The Anthropic-native OAuth route is confirmed, but the opus-4-x[1m] pin is not; the node notes mark fixed-Opus references as legacy.

Caveat on soonwook: the Wiki records a Kimi K3 backend as of 2026-07-20/07-25, but the Kimi base URL is not visible in the login shell and the worker unit exposes no Environment. Whether the worker process still routes to Kimi needs a direct check of its effective environment. Treat the provider column as unconfirmed until then.

What this changes about the fix

The premise "the broker cannot express these capabilities" is no longer the gap. WorkerCapabilities.implementationCapability (capable / runtime / providerId / modelTier / availability) exists on main, is normalized at registration and heartbeat, persists, and is evaluated by evaluateImplementationReadiness() in scheduler-dry-run.ts against the five-clause rule in docs/implementation-lane-readiness.md.

What was missing is that nothing called it. The evaluator has zero runtime callers outside its own test and the read-only readiness-matrix script, so claimTask never consulted it.

There was also a second, separate hole. The #1593 guard in a2a-task-handler.mjs tested task.intent === "implementation", but "implementation" is not a member of A2AExchangeIntent. The guard was unreachable for well-formed tasks while the real implementation intents fell through to the generic_ack success path — so a worker with no executor reported success for patch work. It also covered the docker-runner exception fallback, meaning an executor crash could be recorded as a successful implementation task.

Two PRs, split by side:

• fix(worker): fail closed on real implementation intents in builtin fallback (#1597) #1639 — worker side: fail closed on the real implementation intents instead of returning generic_ack.
• feat(broker): enforce implementation capability at claim time (#1597) #1640 — broker side: wire the existing evaluateImplementationReadiness into the claim path behind an opt-in requireImplementationCapability policy rule, reusing the evaluator verbatim so the dry-run report and the live decision cannot disagree.

Proposal items 1 and 3 are therefore narrower than originally written: the capability schema does not need to be built, and the goal is not to converge every worker onto a Claude-native runtime. The fleet is legitimately heterogeneous (Anthropic native, Codex, possibly Kimi), and the durable fix is for the broker to route on declared capability rather than to homogenize the runtimes. Item 2 — recording the implementation-lane model tier so evidence is interpretable — still stands, and is what the providerId / modelTier fields on the profile are for.

Remaining work after those two PRs: the workers that are implementation-capable do not yet publish an implementationCapability profile, so under an enforce policy they would be denied. Publishing the profile is a per-node change and is tracked separately.