server-exporter

schema/sections.yml + schema/field_dictionary.yml + schema/baseline_v1/ 3종 정합 갱신 (rule 13 R1). schema 변경 후 호출. 사용자가 "schema 정합 갱신", "field dictionary 동기화", "ERD 갱신" (server-exporter 어휘로는 schema doc) 등 요청 시 또는 schema 5개 이상 누적 변경 시 자동. - schema/sections.yml or field_dictionary.yml 수정 후 / 새 섹션 / 새 필드 / Round 검증 후 baseline 변경

구조화된 server-exporter 기능 명세서 작성. 사용자가 "명세서 써줘", "스펙 정리" 등 요청 시. - 구조화된 spec 필요 / PR 본문 / 문서화

server-exporter에 새 벤더(예: Huawei iBMC, Inspur, Ampere)를 3단계로 추가하는 절차 안내. vendor_aliases.yml + adapters/{channel}/{vendor}_*.yml + (선택) OEM tasks + vault + baseline + ai-context + docs 동시 갱신. 사용자가 "Huawei vendor 추가", "새 벤더 추가", "Huawei 지원하자" 등 요청 시 자동 호출. - 새 vendor가 호출자 시스템에서 요청됨 / 펌웨어 프로파일링 후 정식 지원 / 기존 generic fallback 한계 시

사용자 사이트 사고 환경 (HPE Gen12 / Lenovo XCC3 / Dell iDRAC8 / Cisco CIMC 등) 의 fixture를 캡처해 회귀 회피. cycle 2026-05-01 학습 — 사이트 사고 fixture 부재로 다음 reverse regression 위험. 사이트 envelope / probe 결과 / 펌웨어 응답을 tests/fixtures/redfish/{vendor}_{firmware}/ 에 저장 + tests/evidence/<날짜>-<vendor>.md 작성. 사용자가 "사이트 fixture 캡처", "사고 재현 입력 저장" 요청 시.

lab 부재 vendor 추가 (web sources 의무). cycle 2026-05-06 학습 — 4 신규 vendor (Huawei/Inspur/Fujitsu/Quanta) + Superdome Flex 의 lab 부재 web sources 패턴 라이브러리화. 사용자가 "Huawei iBMC 추가", "lab 없는 vendor 어떻게?", "vendor 추가" 등 요청 시 + lab 부재 명시 시. - rule 50 R2 9단계 + rule 96 R1-A web sources 의무 + vault SKIP 사용자 명시 승인

다중 worker cycle 자동화 (Phase 0 ticket 작성 → Phase 1 분석 → Phase 2 결정 → Phase 3 구현 → Phase 4 회귀 → Phase 5 종료). cycle 2026-05-06 학습 — 24 ticket × 5 worker 패턴 라이브러리화. 사용자가 "cycle 시작", "사용자 N 작업 묶음 ticket 으로 분해해줘", "cycle 자동화" 등 요청 시. - 3 항목 이상 작업 묶음 / 다중 worker 동시 진행 / 호환성 / 큰 리팩토링

새 cycle ticket 디렉터리를 cold-start (다음 세션이 컨텍스트 없이 진입 가능) 형식으로 생성. SESSION-HANDOFF + INDEX + DEPENDENCIES + SESSION-PROMPTS + coverage/{section}.md + COMPATIBILITY-MATRIX + LAB-INVENTORY 자동 구성. cycle 2026-05-01 학습 (cold-start 부족) + cycle 2026-05-06 학습 (24 ticket 라이브러리 / 6 절 형식) 형식화. 사용자가 "새 cycle ticket 만들어줘", "cold-start 가이드 작성", "ticket 디렉터리 새로" 등 요청 시.

벤더별 또는 채널별 vault 자격증명 회전 절차. vault/{linux,windows,esxi}.yml + vault/redfish/{vendor}.yml의 password / username 갱신 안내. ansible-vault rekey 또는 외부 BMC 사용자 자체 변경. 사용자가 "Dell vault 회전", "vault password 변경", "rotate" 등 요청 시. - 분기/반기 정기 회전 / BMC 사용자 변경 / 보안 사고 대응 / 자격증명 stale 발견

build_status.yml 4 시나리오 매트릭스 (A/B/C/D) 정합 검증. server-exporter overall.status 판정 로직 (rule 13 R8 + cycle 2026-05-06 M-A 학습). 사용자가 "status 로직 검증", "errors 있는데 success?", "시나리오 매트릭스 확인" 등 요청 시 또는 build_status.yml / build_sections.yml / build_errors.yml 변경 후. - status 판정 의도 검증 / 사용자 의심 (시나리오 B 모순 의심) 재발 차단 / 새 시나리오 추가 시 매트릭스 갱신 / status 로직 정본 변경 후 회귀

단일 agent 작업 신뢰 안 함 — 다중 agent cross-review 강제 워크플로우. cycle 2026-05-01 사용자 명시 ("한 에이전트가 작업한 것을 다른 에이전트가 검수"). 호환성 fix / 큰 변경 / 하네스 자기개선 시 진입. 사용자가 "cross-review", "다중 검수" 요청 시.

lab 보유 / 부재 영역 (vendor / 펌웨어 / OS / 환경) 을 자동 측정해서 LAB-INVENTORY 갱신. cycle 2026-05-01 학습 — lab 한계가 본질적 제약. 사용자가 "lab 인벤토리 갱신", "현재 lab 상태", "부재 영역 list" 요청 시.

lab 부재 vendor / 펌웨어 / 외부 계약 정보를 web 검색 (vendor docs / DMTF / GitHub) 으로 수집해 ticket / adapter origin 주석에 흡수. cycle 2026-05-01 학습 — lab 한계 보완. 사용자가 "Huawei iBMC docs 찾아줘", "DMTF PowerSubsystem 변천 확인", "vendor docs 자동 수집" 요청 시.

4단계 진단 (ping → port → protocol → auth) 어디서 막혔는지 분석. precheck_bundle.py 결과의 diagnosis.details를 해석하고 구체적 해결 방향 제시. 사용자가 "ping은 됐는데 protocol 실패", "auth 단계에서 막힘", "precheck 실패 원인" 등 요청 시. - precheck 실패 발생 / graceful degradation 했지만 일부 데이터 누락 / 새 BMC 응답 없음

다른 세션 / 다른 작업자에게서 인계받은 티켓을 이어받아 구현. 의도 + 제약 + fidelity 판단. 사용자가 "이 티켓 이어받자", "다른 세션 작업 이어가" 등 요청 시. - docs/ai/handoff/ 문서 받아 구현 착수 / 다중 세션 (rule 26)

PR 생성 전 server-exporter 최종 체크리스트. Jenkins 4-Stage 통과 / 4축 리뷰 / 회귀 / docs 갱신 검증. 사용자가 "PR 올리기 전에 확인해줘", "PR 준비됐어?", "체크리스트" 등 요청 시. - PR push 직전 / 머지 직전 최종 검증

새 벤더 / 새 펌웨어 / 의심 응답에 대해 deep_probe_redfish.py로 Redfish API 응답을 전수 프로파일링한다. ServiceRoot부터 Chassis/Systems/Storage/Volumes/Drives/Managers/UpdateService/AccountService 모두 dump 후 vendor adapter 작성을 위한 baseline 자료 생성. 사용자가 "Dell iDRAC 7.x 프로파일", "새 펌웨어 응답 봐줘", "deep probe", "벤더 추가 전 검증" 등 요청 시. - 새 vendor 추가 전 / 펌웨어 업그레이드 후 응답 변경 의심 / 외부 계약 drift 발견 (rule 96)

기존 server-exporter 코드를 4축 (구조 / 품질 / 보안 / 벤더 경계)으로 리뷰. PR 제출 전, 의심 영역 점검, 신규 작업자 온보딩 시. 사용자가 "코드 리뷰해줘", "이 파일 봐줘", "리뷰" 등 요청 시. - 코드 리뷰 일반 / PR 머지 전 / 4축 점검 (rule 22 fragment + rule 12 boundary + rule 60 security + rule 95 quality)

common / 3-channel 코드에 vendor 이름 하드코딩 검출 (rule 12 R1). 사용자가 "벤더 경계 검증", "이 변경 boundary 위반?", "verify boundary" 등 요청 시. - 코드 변경 후 / 새 vendor 추가 후 / PR 머지 전

server-exporter 핵심 규칙인 Fragment 철학 (rule 22) 위반을 검증한다. 각 gather가 자기 fragment만 만드는지, 다른 gather의 fragment를 침범하지 않는지, merge_fragment.yml 호출이 누락되지 않았는지 자동 검사. 사용자가 "fragment 침범 검사", "rule 22 검증", "이 PR이 다른 gather 영역 건드려?" 등 요청 시 또는 gather 코드 변경 후 자동 호출. - gather/normalize 코드 변경 후 / 새 gather 추가 / fragment 의심 패턴 발견 시

새 검증을 어느 layer (Jenkins Stage 1 / precheck 1-4 / Stage 3 / adapter capabilities)에 배치할지 분류 (rule 27 R5). 사용자가 "이 검증 어디에 넣지?", "precheck 단계 분류", "validation layer" 등 요청 시. - 새 입력 검증 / 새 graceful degradation 단계 / Validator 작성 / "어느 단계에서 막을까?" 같은 질의 (server-exporter는 호출자/Stage1)

Jenkins 빌드 / 테스트 실패 로그 분석. 4-Stage 어디서 실패했는지 + 원인 + 수정 방향. 사용자가 "Jenkins 빌드 깨졌어", "파이프라인 실패", "왜 실패?" 등 요청 시. - Jenkins Stage FAIL / 빌드 console log 분석 필요

기능 변경 / 추가 / 리팩토링의 구현 계획 수립. API (callback / Jenkinsfile) 설계 + 채널 영향 + 테스트. 사용자가 "구현 계획 세워줘", "어떻게 만들지" 등 요청 시. - 복잡한 기능 추가 / 변경 전 / task-impact-preview 후 HIGH 리스크

새 섹션 / 새 필드 / Must↔Nice 재분류 / baseline 일괄 갱신 등 schema 변경 계획. 사용자가 "새 섹션 추가하자", "field dictionary에 X 추가", "schema 변경 계획", "Must 필드 추가" 등 요청 시. - 새 섹션 / 새 필드 도입 / 펌웨어 업그레이드로 응답 변경 / Must↔Nice 재분류

origin/main 최신 변경을 fetch하여 자동 분석. 갭 / rule 95 의심 / 하네스 기준 준수 / 영향 vendor 식별. 사용자가 "main 최신 가져와서 체크", "origin 분석", "최근 변경 봐줘" 등 요청 시. - main 최신 동기화 / feature 브랜치 작업 시작 전 / 다른 작업자 머지 후

adapters/{redfish,os,esxi}/*.yml 변경을 점수 / metadata / OEM 분기 / 영향 vendor 4축으로 리뷰. 사용자가 "adapter 리뷰", "이 YAML 변경 봐줘", "adapter score 검토" 등 요청 시. - adapter YAML 추가/수정 후 / 새 vendor 추가 / OEM tasks 변경

vendor fixture 기반 빠른 baseline 회귀. 실장비 없이 mock fixture로 핵심 회귀 점검. 사용자가 "빠른 회귀", "smoke test", "baseline smoke" 등 요청 시 또는 PR 머지 직전. - PR 직전 빠른 점검 / common 변경 후 / 실장비 없는 환경 / Jenkins Stage 4 dry-run

코드 변경이 server-exporter의 5 vendor (Dell / HPE / Lenovo / Supermicro / Cisco)에 미치는 영향 분석. 사용자가 "Lenovo에 영향?", "이 변경 다른 vendor도 영향 있어?", "벤더별 영향" 등 요청 시. - common 또는 3-channel 코드 변경 / adapter 변경 / schema 변경 후 영향 vendor 식별 필요

callback_plugins/json_only.py가 출력하는 JSON envelope 13 필드 정합 검증. server-exporter는 UI 없음 -> 호출자 시스템은 stdout JSON 파싱. 사용자가 "envelope 검증", "callback 출력 형식 맞아?", "JSON 출력 확인" 등 요청 시 또는 callback_plugins / build_*.yml 변경 후. - callback_plugins/json_only.py 수정 / build_output.yml 수정 / envelope 형식 변경 의심 / 호출자 시스템 호환성 확인

새 요구사항 (새 vendor / 새 섹션 / 새 호출자 / Round 검증)을 받아 영향 / 변경 대상 / 테스트 / 리스크 분석. 사용자가 "이 요구사항 분석해줘", "새 기능 영향" 등 요청 시. - 새 요구사항 entry / PO 단계 / task-impact-preview 보다 더 구조화된 분석 필요 시

후보안 2개 이상이 있을 때 영향 / 리스크 / 비용 축으로 비교 매트릭스. 사용자가 "두 방법 비교", "어떤 게 나아?" 등 요청 시. - 후보안 2+ / 비교 근거 필요

외부 시스템 (Redfish / IPMI / SSH / WinRM / vSphere) 연동 기능 버그 조사 시 systematic-debugging 진입 전 호출. 외부 계약을 사용자에게 먼저 질의하여 추측 턴 낭비 차단 (rule 96 R2). 사용자가 "Redfish 응답 이상", "vSphere 연결 실패", "외부 시스템 디버그" 등 요청 시. - 외부 시스템 연동 버그 / 응답 형식 불명 / 펌웨어 차이 의심

모호한 요구사항을 사용자와 대화로 좁혀 기능 방향 결정. discovery 루프 진입점. 사용자가 "어떻게 만들지 같이 생각해줘", "방향이 애매해" 등 요청 시. - 요구가 모호 / 여러 해석 가능 / 바로 구현 불가

server-exporter 하네스 자기개선 1 cycle 수동 트리거. 6단계 파이프라인 (observer → architect → reviewer → governor → updater → verifier). 사용자가 "/harness-cycle", "harness 사이클" 등 요청 시. - 정기 자기개선 / 사용자 피드백 수렴 / drift 누적 후

server-exporter 하네스 전수조사 + Tier 1/2 일괄 수정. 시니어 인수 모드. 사용자 명시 요청만. 사용자가 "전수조사", "full sweep", "하네스 싹 정리" 등 명시 시. - 1회성 대형 작업 / 사용자 명시 요청만 (자동 트리거 금지)

rule 28 R1 카탈로그 11종 측정 대상을 TTL / 무효화 trigger 기반으로 재측정 또는 캐시 사용 판정. 사용자가 "실측해줘", "최신 정보 맞아?" 요청 시 또는 장기 세션 중간 동기화. - 코드 작업 시작 전 / 측정 대상 stale 의심 / 사용자 명시 요청

rule 41 mermaid 작성 가이드. 다이어그램 작성 / 검토 시 참조. 사용자가 "mermaid 가이드", "다이어그램 컨벤션" 등 요청 시. - 다이어그램 작성 시 rule 41 lookup 필요

PO 단계 기획 artifact 생성. 명세 / 흐름도 / 영향 분석을 함께. 사용자가 "새 기능 기획해줘", "명세 만들어줘" 등 요청 시. 실제 작업은 product-planner agent에 위임. - 새 기능 기획 단계 / 구현 전 artifact 묶음 필요

디렉터리 / 명명 / 모듈 경계 정리 계획. 기능 변경 없는 lane. 사용자가 "구조 정리", "폴더 통일", "naming convention" 등 요청 시. - 디렉터리 / 네이밍 / 경계 정리 (기능 변경 없음)

변경된 코드 기반 회귀 테스트 대상 선정 + 테스트 계획. 사용자가 "어떤 테스트 돌려야 해?", "회귀 검사" 등 요청 시. - 코드 변경 후 / PR 머지 전 / Jenkins Stage 4 사전 점검

후보안 비교 후 1개 추천안 + 근거 제시. 사용자가 "추천해줘", "결정 마비 상태" 등 요청 시. - compare-feature-options 출력 후 결정 단계