Unified Notifications Ops

• 토큰, 시크릿, 웹훅 시크릿, 내부 식별자를 절대 노출하지 않습니다.
• 다음 요소를 분리해서 다룹니다.
  • 이벤트 소스
  • 심각도
  • 라우팅 채널
  • 운영자 액션
• 중단 비용이 불명확하면 기본은 digest-first입니다.
• 모든 이벤트를 모든 채널로 퍼뜨리지 않습니다.
• 진짜 해결책이 더 나은 이슈 트리아지, 훅 정책, 프로젝트 흐름이라면 그 점을 명시합니다.

이벤트 파이프라인

알림 경로를 다음 단계로 취급합니다.

1. Capture the event
2. Classify urgency and owner
3. Route to the correct channel
4. Collapse duplicates and low-signal churn
5. Attach the next operator action

목표는 더 적지만 더 좋은 알림입니다.

기본 심각도 모델

워크스페이스에 심각도 모델이 없다면 자동화를 제안하기 전에 먼저 만듭니다.

워크플로

1. 현재 표면 인벤토리 작성

다음을 나열합니다.

• event sources
• current channels
• existing hooks/scripts that emit alerts
• duplicate paths for the same event
• silent failure cases where important things are not being surfaced

ECC가 이미 소유하고 있는 표면을 명확히 표시합니다.

2. 어떤 이벤트가 인터럽트를 유발할지 결정

각 이벤트 군마다 다음 질문에 답합니다.

• who needs to know?
• how fast do they need to know?
• should this interrupt, batch, or just log?

기본값은 다음과 같습니다.

• 릴리스, CI, 보안, 담당자 차단 이벤트는 즉시 인터럽트
• 중간 신호 업데이트는 digest
• 텔레메트리와 저신호 생명주기 마커는 로그만 남김

3. 채널을 늘리기 전에 중복부터 접기

다음을 찾습니다.

• the same PR event appearing in GitHub, Linear, and local logs
• repeated hook notifications for the same failure
• comments or status churn that should be summarized instead of forwarded raw
• channels that duplicate each other without adding a better action path

다음 원칙을 우선합니다.

• one canonical summary
• one owner
• one primary channel
• one fallback path

4. ECC 네이티브 워크플로 설계

실제 알림 요구마다 다음을 정의합니다.

• source
• gate
• shape: immediate alert, digest, queue, or dashboard-only
• channel
• action

ECC에 이미 해당 원시 기능이 있다면 다음을 우선합니다.

• 운영자 트리아지를 위한 스킬
• 자동 발행/강제를 위한 훅
• 위임 분류를 위한 에이전트
• 실제 브리지가 부족할 때만 MCP/커넥터

5. 액션 중심 설계안 반환

최종 결과에는 다음을 포함합니다.

• what to keep
• what to suppress
• what to merge
• what ECC should wrap next

출력 형식

CURRENT SURFACE
- sources
- channels
- duplicates
- gaps

EVENT MODEL
- critical
- high
- medium
- low

ROUTING PLAN
- source -> channel
- why
- operator owner

CONSOLIDATION
- suppress
- merge
- canonical summaries

NEXT ECC MOVE
- skill / hook / agent / MCP
- exact workflow to build next

권고 규칙

• 약한 경로 여러 개보다 강한 경로 하나를 우선합니다.
• 중간/저신호 업데이트는 digest를 우선합니다.
• 신호가 자동 발행돼야 한다면 훅을 우선합니다.
• 작업이 트리아지, 라우팅, 리뷰 우선 의사결정이라면 운영자 스킬을 우선합니다.
• 근본 원인이 알림이 아니라 백로그/PR 조정이라면 project-flow-ops를 우선합니다.
• 먼저 소스 인벤토리가 필요하다면 workspace-surface-audit를 우선합니다.
• 데스크톱 알림만으로 충분하다면 불필요한 외부 브리지를 만들지 않습니다.

좋은 사용 사례

• "We have GitHub, Linear, and local hook alerts, but no single operator flow"
• "Our CI failures are noisy and people ignore them"
• "I want one notification policy across Claude, OpenCode, and Codex surfaces"
• "Figure out what should interrupt versus land in a digest"
• "Collapse overlapping notification PR ideas into one canonical ECC lane"

관련 스킬

• workspace-surface-audit
• project-flow-ops
• github-ops
• knowledge-ops
• customer-billing-ops when the notification pain is billing/customer operations rather than engineering