동작 흐름

한 번의 실행은 트리거 → 세션 시작 → 대응 → 지켜보기 → 기록 순서로 흘러가요.

1. 트리거

스캐너가 POST /api/trigger 로 목록을 보내요. autofix 는 AUTOFIX_TOKEN 을 확인하고 이렇게 나눠요.

경우	응답	기록
목록이 비었어요	200 {"skipped": "남은 취약점 없음"}	남기지 않아요
이전 실행이 진행 중이에요	202 {"status": "skipped"}	건너뜀 하나
그 밖	202 {"status": "working"}	대응 중 하나, 세션 시작

형식과 오류는 HTTP API를 보세요.

2. 첫 메시지 만들기

세션은 사람 없이 돌기 때문에 첫 메시지에 필요한 것을 전부 담아요.

1. 머리말: 실행 id, 출처, 건수, 그리고 "사람 확인 없이 끝까지, push·배포까지 승인됨".
2. 목록: 심각도 순(CRITICAL → HIGH → MEDIUM → LOW)으로, 같은 심각도는 레포·패키지 이름 순. 한 줄에 심각도, 레포, 파일, 패키지, 지금 버전 → 고친 버전, 권고 번호, 범위.
3. 규칙: 내장 규칙 또는 RULES_FILE. 안의 {{workdir}} 는 BRIDGE_WORKDIR 로 바뀌어요.

실제 모양은 내장 규칙과 프롬프트에 있어요.

3. 세션 시작

autofix 가 agent-bridge 의 서비스 API 를 불러요. agent-bridge 는

• BRIDGE_HOST 로 그 사람의 맥을 찾고(id 또는 이름, 대소문자 무시),
• 맥이 연결돼 있지 않으면 거절하고(그러면 실행은 실패),
• BRIDGE_WORKDIR 에서 안전한 전부 허용 모드, Chrome 연동 끔으로 세션을 열어요.

세션은 그 사람의 보통 세션처럼 agent-bridge 화면에 보여요. 지켜보다가 직접 끼어들 수도 있어요.

4. 대응

세션이 규칙대로 일해요. 내장 규칙 기준으로는

1. 레포마다 기본 브랜치를 pull 하고 git worktree 에서 작업해요.
2. 고친 버전으로 올려요. 안 되면 resolutions·overrides 를 써요.
3. 못 고치면 사용 경로를 확인하고 보류로 남겨요.
4. lint·typecheck·test·build 를 통과시켜요.
5. 커밋하고 기본 브랜치에 push 해요.
6. 배포 파이프라인이 있으면 배포와 라이브를 확인해요.
7. 마지막에 항목별 결과, 커밋 해시, 배포 결과를 짧게 정리해요.

5. 지켜보기와 기록

autofix 는 1분마다 진행 중인 실행의 세션 상태를 읽어요. 세션이 사람을 기다리면 확인 대기, 답을 마치고 2분이 지나면 완료, 제한 시간을 넘기면 시간 초과로 바꿔요. 판정 규칙은 실행의 일생을 보세요.

결과에는 세션의 마지막 답변이 그대로 들어가요. 그래서 규칙의 마지막 항목을 "결과를 짧게 정리"로 두는 게 중요해요.