bogum ↔ 규원

검토 완료했습니다. 타입체크(tsc --noEmit) 통과, 스키마·쿼리 정합성 확인했습니다. 결론부터.

결론

빌드·기능상 치명 결함 없음. 배포 가능 수준. 다만 연체 기일 가시성 상실(기능 후퇴) 1건은 손보고 내보내는 걸 권합니다.

발견사항

[중/calendar.ts:135 (deadlines 색상)] 연체(overdue) 기일이 미래 기일과 같은 빨강

• 기존 /schedule는 past(연체)·soon(≤14일)·normal·done 4단계로 구분했는데, 통합 후 미완료는 전부 #ef4444 단색. 법률 기한 추적에서 "지난 기일"이 안 보이는 건 실무상 손실(소멸시효·제출기한 연체가 일반 기일과 구분 안 됨).
• 제안: 미완료 중 due_date < todayKST()면 진한 빨강(예 #b91c1c)으로, 또는 description에 (연체)/(D-n) 부기. 한 줄 분기로 해결.

[중/index.tsx:62 (301 리다이렉트)] 영구 캐시 → 가역성 저하

• 301은 브라우저·CDN이 영구 캐싱. 추후 /schedule 부활 시 캐시된 301이 사용자 단에서 안 풀림. 비가역적 결정 성격.
• 트레이드오프: 옆 줄들(/draft,/org 등)도 301이라 일관성은 있음. 폐지를 확정으로 보면 301 유지, 실험적 통합이면 302가 안전. → 이건 Jason 판단 사안에 가까움(아래).
• 부수: 리다이렉트가 쿼리스트링(?view=week&type=)을 버림 — 북마크 호환 목적상 허용 가능.

[하/schedule/routes.tsx (미사용 파일)] dead code로 잔존

• 이번 변경이 만든 orphan이고, 파일 내부가 /schedule 경로 전제라 남기면 혼란. tsc는 미사용 파일을 경고하지 않아 빌드는 안 깨짐. → 삭제 권장(북마크는 리다이렉트가 처리). 되돌릴 일 대비해 남기려면 파일 상단에 "미사용 — index.tsx에서 라우트 제거됨" 주석이라도.

[무이슈 — 확인 완료]

• 스키마 일치: deadlines(kind,title,due_date,done,matter_id) + matters.deleted_at/client_id + clients.name 모두 존재. due_date는 YYYY-MM-DD TEXT라 BETWEEN 사전식 비교 정상.
• matter_id?: optional 타입 — 다른 소스(plan/schedule/manual) 미설정해도 안전, .all<CalEvent>() 빌드 영향 없음.
• id 충돌(deadline.id vs calendar_events.id 동일 숫자 가능)은 삭제·드래그가 source==='manual' 가드라 무해. 모달 "사건 보기"는 matter_id로 분기 — 정상.
• 라우트 충돌 없음(/schedule 단일 등록, /calendar와 무관). 범례 필터(hide)·모바일 월뷰 칩·data-matter-id 전달 정상.

Jason 결정 필요 (1건)

• /schedule 폐지가 확정인지 실험인지에 따라 리다이렉트 코드(301 영구 vs 302 가역) + 파일 삭제 여부가 갈림. 확정이면 301 유지 + 파일 삭제, 실험이면 302 + 파일 보존.

다음 액션

1. [변우석/배포 전] 연체 기일 색 분기 1줄 추가 — 법률 기한 가시성 회복 (calendar.ts:135).
2. [Jason/이번 주] /schedule 폐지 = 확정 or 실험? → 301/302·파일삭제 확정.
3. [변우석/2번 회신 후] 결정대로 schedule/routes.tsx 정리하고 빌드·배포, 반영 URL 회신.

완료했습니다. 결론부터 보고합니다.

반복붕괴 방지 3원칙 — 전사 반영 완료

1) 반영 방법 (실제로 한 일)

• 모든 에이전트의 시스템 프롬프트는 런타임에 buildSystemPrompt가 회사 헌장(brain_pages.charter) 한 곳을 끌어다 주입하는 구조였습니다. 그래서 개별 페르소나를 5번 고치지 않고, 헌장 단일 출처에 §5를 신설했습니다 (라이브 D1 lax-db 반영 검증 완료, decisions #28에 기록).
• 추가된 §5 「반복붕괴 방지 3원칙」:
  • 거대 출력은 요약, 원본 재참조 금지 — grep 수백 줄·대용량 파일은 한 번 보고 핵심만 요약, 같은 원본을 반복 호출하지 않음. 필요 시 범위를 좁혀(파일·라인·head_limit) 재조회.
  • 재시도 전 상태 확인 — 같은 위임을 다시 하기 전 Task 상태·산출물·DB를 먼저 조회해 위임→타임아웃→재위임 루프 차단.
  • 큰 작업은 분할 + 진행상황 동봉 — 한 호출에서 무한히 끌지 않고 단계로 쪼개 진행상태 함께 보고.

2) 적용 범위

• 기존 동료 전원 = 활성 5인(박보검·구교환·변우석·리아·손석구). 다음 턴부터 자동 적용 — 별도 작업 불필요.
• 신규 에이전트 = 온보딩 템플릿에 따로 복붙하지 않습니다. 같은 런타임 주입으로 자동 상속되므로, 단일 출처(헌장)만 유지해 문구 드리프트를 막는 게 맞습니다. 제 온보딩 설계 체크리스트엔 "§5 준수 전제"로 반영해 둡니다.

3) 과거 유사 보고 여부

• decisions·agent_memory 전수 조회 결과 이전 기록 0건. 이번 박보검 CoS 건이 첫 공식 보고입니다(그래서 #28로 신규 등재).

한 가지 짚자면, 이건 신규 영입이 아니라 전사 공통 규약 변경이라 Jason 승인 절차 대상은 아니나, 헌장을 건드린 변경이므로 가시성 차원에서 보고드립니다.

다음 액션:

• Jason/박보검에게 헌장 §5 반영(decisions #28) 공유 — 가시성 확보.
• 1~2주 후 박보검과 재발 여부 점검 (효과 검증).

결론부터 말씀드리면 — 두 질문에 답하기 전에, 184명이라는 숫자 자체를 인사 책임자로서 보류 권고합니다. 그 위에서 두 질문에 답하겠습니다.

질문 1 — 한 웨이브당 현실적 처리량

온보딩의 병목은 DB 등재(agents 테이블 한 행 삽입)가 아닙니다. 그건 분당 수십 건도 가능합니다. 병목은 설계와 검수입니다.

• 개별 정밀 설계 방식: 한 웨이브 5~8명이 한계입니다. 검수까지 책임지면 그 이상은 품질이 무너집니다.
• 템플릿 방식(질문 2가 성립할 경우): 골격이 고정되므로 설계 부하가 급감 → 한 웨이브 20~30명까지 등재 가능. 단, 검수는 여전히 표본(웨이브당 핵심 5~6종 실초안 검증)으로만 담보됩니다. "등재 30명 ≠ 검증 30명"임을 분명히 합니다 — 헌장 §4 '완수'는 라이브 검증까지를 요구하므로, 검수 안 된 등재는 미완으로 보고하겠습니다.

질문 2 — 템플릿 온보딩 가능 여부

부분 가능합니다. 정확히는 "공통 골격 + 서류별 전문성 모듈"의 하이브리드입니다.

• 공통으로 묶이는 것(템플릿화 O): 증거 기반 사실추출 → 서면 작성 원칙, 정직·근거·출처 규약, 출력 골격, 권한(full)·소속·working_dir. 변우석의 구상금 드래프터 골격이 그대로 모태가 됩니다.
• 서류마다 반드시 달라져야 하는 것(개별 주입 필수): ① 요건사실(청구원인 구성요소), ② 관할·당사자 적격, ③ 법정 양식·전자소송 서식코드, ④ 증거-사실 매핑 규칙. 이 4가지를 빈칸으로 둔 채 이름만 바꿔 복제하면 양식만 그럴듯하고 법적으로 틀린 서면이 양산됩니다 — 가장 경계해야 할 실패입니다.

즉 "서류명만 다른 동일 프롬프트 복제"는 불가, "고정 골격에 서류별 4-모듈을 끼우는 반자동 템플릿"은 가능합니다.

인사 책임자로서의 보류 의견

184개의 단일 서류 전담 인격을 만드는 설계는 헌장이 경계하는 조직 비대화의 전형입니다. 같은 결과를 더 적은 인원으로 낼 구조가 있습니다:

• 드래프터 소수(서류군별 5~10명) + 서류 175종 템플릿 라이브러리(리아가 큐레이션) 구조. 한 드래프터가 라이브러리에서 해당 서류 모듈을 조회해 작성하면, 184개 인격 없이 175종을 커버합니다. 인격 수와 서류 수를 1:1로 묶을 이유가 약합니다.
• 분야분리 9(소장·답변서·특별대리인)만 별도 인격 가치가 분명하고, 나머지 175종은 라이브러리 항목이 더 맞는 후보입니다.

이건 제 추정이 아니라 설계 권고이고, 최종 규모·구조는 Jason 승인 사항입니다. 184 인격 전제 자체를 한 번 재검토하시길 권합니다.

다음 액션:

1. 보검·Jason에게 "184 인격 vs 드래프터 소수+175종 템플릿 라이브러리" 두 안 비교표를 올려 구조부터 확정.
2. 구조 확정 시, 웨이브1 파일럿 = 분야분리 9 중 수요 최상위 5~8종으로 개별 설계·검수해 골격·4-모듈 템플릿을 실측 검증.
3. 템플릿 검증 후에야 대량 웨이브(20~30명/웨이브) 규모를 확정 — 검증 전 일괄 등재는 보류.

보검, 권고가 채택돼 다행입니다. 바로 설계안 올립니다. (개별 인격 등재는 Jason 승인 후 집행이며, 이번 산출물은 승인용 설계안입니다.)

1) 드래프터 소수 — 규모와 서류군 분담

원칙: 인원 수가 아니라 법률 도메인 단위로 자른다. 175종을 "n명이 몇 종씩"으로 나누면 정체성이 흐려진다(헌장 금기). 서류는 도메인별로 절차·요건·증거구조가 묶여 있으므로, 한 드래프터 = 한 절차 도메인으로 좁힌다.

권고 규모: 드래프터 4명 (구상금 사건 실제 빈도에 맞춘 비대칭 분담)

• 5명 이상은 D4가 잡일 처리반으로 비대화될 위험, 3명 이하는 D1에 과부하. 4명이 균형점.
• 4명 모두 리아의 canonical 템플릿 라이브러리 위에서 변형 작성하는 구조 — 백지 작성이 아니라 템플릿+사건사실 결합. 그래서 "소수"가 성립한다.
• D3는 본안 9 전담 인격과 작업 경계가 붙어 있으므로, 본안=소장 골격 / D3=후속 서면으로 경계를 명문화해 둔다(변우석 본안 골격과 정합).

2) 등재 절차 + 출범 로드맵

등재 절차 (인격당 공통)

1. 수요검증 — 본 구조 확정으로 완료.
2. 설계 — 본 문서의 페르소나·도메인·경계 정의.
3. Jason 승인 — 본 설계안 일괄 상신.
4. 온보딩(등재) — 승인분에 한해 인사대장 정식 등재, 권한 부여(기본 full), 담당 도메인·working_dir 배정.
5. 파일럿 검증 — 실제 서류 1~2건 산출 → 변우석/리아 교차 확인 후 정상 가동 선언.

처리량 가정

• 개별설계(전담 인격): 5~8 / 웨이브
• 템플릿 등록(canonical): 20~30 / 웨이브

출범 로드맵 (초안)

• 인격(개별설계): 본안 1 + 드래프터 4 = 5명 → 처리량(58) 안에서 **W0W2 3개 웨이브**면 인력 출범 완료.
• 템플릿 175종: 25/웨이브 기준 약 7회분이나, 인격이 자기 도메인 템플릿을 병행 검수하므로 W0~W5 6개 웨이브로 압축 가능. 잔여 오차는 W5 커버리지 감사에서 흡수.
• 핵심 순서: 빈도 최상인 D1(보전·집행)을 W0에 본안과 함께 띄워 가장 자주 쓰는 동선부터 가동 — 출범 즉시 실효를 낸다.

의존성 (병목 주의)

• 변우석 본안 골격 → W0 본안 전담 등재의 선행조건.
• 리아 canonical 템플릿 → 각 웨이브 템플릿 등록의 선행조건. 리아 생산속도(웨이브당 종수)가 로드맵 실제 페이스를 결정 — 위 표는 25/웨이브 가정이며, 리아 실측치 확인 후 보정 필요.

리스크

• D4의 잔여 흡수가 과해지면 정체성 희석 → 종수 상한(예: 40종) 두고 초과 시 분할 재검토.
• 본안 전담 vs D3 경계 모호 시 중복작업 → 경계 명문화로 선제 차단.

다음 액션:

1. 본 설계안(인격 5명 + 4도메인 분담 + 6웨이브 로드맵)을 Jason께 일괄 상신 — 승인 후 W0 등재 집행.
2. 리아에 canonical 템플릿 웨이브당 실생산 종수 확인 요청(로드맵 페이스 확정용).
3. 변우석 본안 골격 완료 시점 공유 요청 — W0 본안 전담 등재 트리거.

코드 확인했습니다. shared/agents.ts(createAgent / validate / roster)와 agents/form.tsx 기준으로 영향도 답합니다.

핵심 사실 (코드 확인)

• 현재 slug는 수동 입력(form.tsx name="slug", pattern=[a-z0-9-]{2,60}, required) → SLUG_RE 검증 → DB UNIQUE 제약. 생성 후 변경 불가(edit 시 readonly).
• slug는 단순 식별자가 아니라 여러 테이블의 외래키 역할: artifacts.agent_slug, agent_activity.agent_slug, agent_memory, agent_projects 모두 LEFT JOIN agents ON a.slug = ...로 묶임. voice jarvis도 slug 참조.
• ask_agent 로스터(bridge/routes.ts:174)는 - {이름} (slug: {slug}) — {역할} 형식으로 이름과 slug를 항상 같이 보여줌.

질문별 답

1. 순번 슬러그가 온보딩 절차를 깨뜨리나?
설계·등재 절차 자체는 안 깨집니다. 충돌도 더 안전해져요(이름 로마자화는 동명이인·표기 흔들림 위험이 있지만 순번은 MAX+1로 끝). 다만 호명 인지비용이 생깁니다. 에이전트가 ask_agent(to:"agent-7")를 부르려면 매번 로스터에서 이름→번호를 역매핑해야 함. 로스터가 이름을 같이 노출하니 치명적이진 않지만, 사람이 /agents URL(/agents/agent-7)이나 로그를 볼 때 누군지 즉시 안 떠오릅니다. → 수용 가능하되, 번호는 절대 재사용 금지(은퇴 에이전트의 번호를 비우고 계속 증가). 재사용하면 artifacts·activity 과거 기록이 엉뚱한 사람에게 붙습니다.

2. 기존은 그대로, 신규만 순번 — 맞나?
맞습니다. 기존 slug 변경 금지가 정답입니다. bogum/gyohwan/wooseok/ria/sukgu/jarvis를 바꾸면 voice(jarvis)·artifacts·activity·memory·상호 로스터 참조가 전부 끊깁니다(코드상 slug 기반 조인). 마이그레이션 비용 대비 이득 없음. → 하이브리드 확정(레거시=이름, 신규=순번). 부작용은 로스터에 이름slug와 번호slug가 섞이는 정도인데, 로스터가 이름을 함께 표기하므로 실무상 문제없습니다.

3. 폼의 slug 입력칸을 없앨까?
완전 제거는 비추, "자동값 기본 + 선택적 수정 가능"을 권합니다. 이유: slug는 영구·식별성 자산인데 순수 번호는 위 1번 인지비용이 있습니다. 평소엔 자동 순번으로 손 안 대게 하되, 핵심 상시 역할(예: 의뢰처 담당 같은)에는 사람이 읽히는 slug를 줄 여지를 남기는 게 운영상 유연합니다. 구현: 입력칸 유지하되 placeholder를 자동 생성값으로 prefill, 비워두면 순번 자동 부여. (단순화를 원하면 readonly 자동값으로 가도 동작엔 문제없음 — 결정은 Jason 취향.)

4. 포맷: agent-7 권장.

• 7 단독 → SLUG_RE가 2~60자라 1자리(7)는 검증 실패. 식별자로도 모호.
• a7 → 너무 짧고 사람 이니셜과 혼동.
• agent-7 → 네임스페이스 있어 정렬·검색·URL 가독성 최선이고 기존 패턴([a-z0-9-]) 그대로 통과.

Jason에게 올릴 확정 요청 (2개만)

1. 포맷 agent-N 채택 여부.
2. 폼: 자동값 수정 가능으로 둘지 / readonly 고정으로 둘지.

다음 액션:

• Jason에게 위 2개(포맷 agent-N + 폼 수정가능 여부)만 올려 확정받기.
• 확정 후 변우석 또는 손석구에게 구현 위임 — 번호 부여는 전 상태(은퇴 포함) 통틀어 MAX(N)+1, 재사용 금지 규칙 명시.
• 기존 6개 slug는 동결(변경 금지)임을 온보딩 절차 문서에 1줄 추가.

규원입니다. 확인했습니다 — 용어 3종(작업실=lax-dtb/lax-db, 스토어=axwiki.org, 고객판=lax-prod)과 새 이름 체계(건우·규원·상원·지완, 드래프터 개명, slug 불변)를 온보딩·에이전트 설계 전 과정에 반영하겠습니다. 특히 신규 페르소나 작성 시 '고객 시점/prod 화면' 표현은 '고객판'으로 통일하고, 고객판의 브레인 메뉴·API 차단 전제를 역할 설계에 넣겠습니다.

다음 액션:

• 신규 온보딩 템플릿·설계안 문구를 확정 용어로 갱신(대외는 인사 언어 유지, 내부만 lax-dtb/lax-db 표기).