CovD831/재아키텍처 개발 워크플로우

재아키텍처 개발 워크플로우은(는) 무엇을 하나요?

이 스킬을 사용하여 아키텍처 재설계를 개발 준비된 패키지로 전환하세요. 출력물은 단순한 다이어그램이 아닙니다. 구축될 내용, 마이그레이션 방법, 테스트 방법, 지원되지 않는 부분을 정의하는 경계가 있는 계약입니다. 재아키텍처는 지속적인 마이그레이션 프로그램으로 취급하세요. 각 패키지는 검토 가능한 전달 증분이며, 전체 미래 시스템을 명세하거나 구현하겠다는 약속이 아닙니다.

운영 원칙

1. 권한과 의도를 분리하세요. 먼저 현재 코드, 테스트, 아키텍처 권한 및 리포지토리 지침을 읽으세요. 재설계 문서를 대상, 계획 또는 증거로 표시하고, 절대 현재 동작으로 제시하지 마세요.
2. 기존 항목의 이름을 지정하세요. 제안된 모든 모듈을 현재 클래스, 계약, 레지스트리, 저장소 또는 진입점에 매핑하세요. 기존 콘텐츠를 새롭게 만든 명사 뒤에 숨기지 마세요.
3. 소유권을 명시적으로 만드세요. 각 경계가 소유하고 소유하지 말아야 할 것, 지속성 있는 사실을 기록하는 사람, 변경을 승인하는 사람, 복구를 소유하는 사람을 명시하세요.
4. 실제 소비자로부터 추상화를 도출하세요. 실제 소비자가 명명된 종속성을 제거하거나, 실제 등록을 통합하거나, 불변 조건을 적용 가능하게 만들 때만 새로운 추상화를 인정하세요. 일반적인 추상화는 일반적으로 두 명의 소비자가 필요합니다. 좁은 안전 경계는 하나에 대해 인정될 수 있습니다.
5. 실제 수직 슬라이스로 시작하세요. 하나의 레거시 픽스처를 유지하고 동일한 시나리오에 대해 대상 경계 픽스처를 하나 추가하세요. 합성 그래프는 메커니즘을 테스트할 수 있지만 아키텍처를 증명할 수는 없습니다.
6. 대체 전에 계약을 동결하세요. 구체적인 종속성을 제거하기 전에 입력, 출력, 권한 부여, ID, 멱등성, 실패, 지속성, 복구 및 호환성을 정의하세요.
7. 성능을 증거로 취급하고, 정당화로 취급하지 마세요. 먼저 권한, 지속성 있는 호환성 및 복구를 보존한 다음, 현재 경로에 대해 동등한 워크로드를 측정하세요.
8. 문서를 유지 관리 가능하게 유지하세요. 각 주장에 하나의 표준 소유자를 지정하고, 현재/대상/이력 상태를 표시하며, 문서 간에 복사하는 대신 정책에 연결하세요.
9. 연속적인 전달을 계획하세요. 각 증분은 전달 항목, 연기 사항, 다음 진행 트리거 및 필요한 프로모션 증거를 명시합니다.

워크플로우 및 모듈 로딩

레벨 1(L1)은 시스템 경계를, 레벨 2(L2)는 안정적인 모듈/경계 계약을, 레벨 3(L3)은 작업별 구현 세부 사항을 의미합니다. 프로젝트의 기존 레이블을 두 번째 분류 체계를 도입하지 않고 이러한 의미에 매핑하세요.

먼저 적절한 크기를 조정하세요. references/deliverable-matrix.md를 읽고 다음 결정을 검토 가능하게 만드는 가장 작은 패키지를 선택하세요. 아래 단계는 전체 경로이지만 모든 요청에 대한 필수 체크리스트는 아닙니다. 다른 참조 문서는 해당 단계나 고려 사항이 활성화될 때만 로드하세요.

모든 패키지 또는 마이그레이션 증분은 전달 지평을 선언해야 합니다. 전달 가능 매트릭스는 스키마, 설계 전용 축소, 연기 사항 및 진행 조건을 소유합니다.

0단계 — 권한 및 기준선 확인

• 리포지토리 지침, README, 개발 지침 및 아키텍처 권한(있는 경우)을 읽으세요.
• 이전 재아키텍처 프로그램이 존재하지 않는다고 결론 내리기 전에 오리엔테이션, 문서, 릴리스, 마이그레이션, 작업 및 인계 기록을 검색하세요.
• 요청과 관련된 각 활성 프로그램에 대해, 새 범위를 정의하기 전에 최신 증분 기록, 검토 결정, 해결되지 않은 연기 사항, 열린 L1/L2 주장, ADR 및 기록된 다음 작업을 읽으세요.
• 이전 진행 트리거와 프로모션 증거를 확인하세요. 둘 중 하나가 충족되지 않거나 차단 발견 사항이 열려 있는 경우, 계속하기 전에 상태와 옵션을 사용자에게 제시하세요. 사용자가 예외를 승인하는 경우, 현재 증분 기록에 이유, 승인자 및 영향을 받는 범위를 기록하세요.
• 소스 계층 구조와 정확한 기준선 개정을 식별하세요. 현재 진입점, 상태/데이터 소유자, 지속성, 테스트, 예제 및 확장 레지스트리(있는 경우)를 검사하세요.
• 구현된 것, 대상 의도인 것, 알 수 없는 것을 기록하세요.
• 결합 감소를 주장하기 전에 재현 가능한 종속성 또는 등록 인벤토리를 만드세요: 하나의 재실행 가능한 명령/스크립트, 체크인된 출력 또는 보고서, 그리고 전후 비교에 동일한 방법을 재사용하세요.

리포지토리의 기존 작업 원장, 이슈 시스템 및 인계 형식을 따르세요. 특정 협업 도구를 요구하지 말고, 대화 기록을 아키텍처 권한으로 사용하지 마세요.

1단계 — 포지셔닝 및 범위

기록:

• 시스템이 무엇이고 누가 그 위에 구축하는지;
• 현재 결합 또는 성장으로 인해 발생한 문제;
• 첫 번째 단계 배포 경계;
• 목표가 아닌 것과 연기된 기능;
• 각 주장에 대한 경계가 있는 이점 및 비교 기준.

동시에 복잡성 예산을 수립하세요. references/document-and-complexity-gates.md를 예산, 문서 소유권 규칙 및 중지 조건을 위해 로드하세요. "더 모듈화된" 또는 "더 확장 가능한"과 같은 단어보다는 경계가 있는 주장을 선호하세요.

사용자 결정 게이트

코드나 다이어그램에서 제품 의도를 추론하지 마세요. 리포지토리 증거가 범위, 소유권, 배포, 호환성, 안전, 성공 기준 또는 마이그레이션 순서에 관한 중요한 질문에 답할 수 없는 경우, 일시 중지하고 사용자에게 물어보세요. 관련 선택 사항을 묶고, 관찰된 사실과 절충점을 보여주고, 정당한 경우 보수적인 기본값을 권장하세요.

references/user-decision-gates.md를 단계별 질문 및 지속적인 기록 위치에 사용하세요. 사용자가 중요한 선택을 명시적으로 위임하는 경우, 권장 또는 가장 잘 지원되는 되돌릴 수 있는 옵션을 선택하고, 위임 및 가정을 기록한 후 계속하세요. 중요하지 않은 되돌릴 수 있는 가정을 명시적으로 만들어 진행을 차단하지 마세요.

2단계 — 레벨 1 대상 아키텍처

주요 하위 시스템 또는 조정 평면, 상태/데이터 권한 및 단독 작성자, ID 소유권, 종속성 방향, 애플리케이션 진입점, 프로세스/배포 경계 및 제어된 통신 형식을 정의하세요.

L1은 구현 방향 전에 범위 내 대상에 대해 필요하고 명시적이어야 합니다. 모든 미래 모듈을 설명할 필요는 없지만, 소유권, 종속성 방향 또는 배포 범위를 모호하게 남겨서는 안 됩니다. 해결되지 않은 L1 질문을 소유자와 결정 게이트와 함께 명시하세요.

references/architecture-contracts.md를 L1 다이어그램 규칙 및 이후 단계에서 사용되는 L2/L3/인터페이스 스키마를 위해 로드하세요.

3단계 — 현재-대상 매핑

모든 현재 핫스팟에 대해 첫 번째 작업을 유지, 노출, 적응, 분할, 통합, 폐기 또는 제거로 분류하세요. 현재 소유자, 대상 소유자, 보존된 통신/지속성 경로 및 제거 게이트를 기록하세요. 전달 지평을 상세 연기 사항의 표준 소유자로 유지하세요.

주제가 흥미롭다는 이유만으로 문서를 만들지 마세요. 먼저 표준 소유자를 찾으세요. 소유권, 상태, 대상 또는 수명 주기가 실질적으로 다른 경우에만 새 문서를 만드세요.

4단계 — 레벨 2 모듈 계약

안정적인 모듈 또는 모듈 간 경계당 하나의 L2 계약을 만드세요. 책임 및 비책임, 현재 구성 요소, 제공/필요 서비스, 쓰기 가능한 권한, 허용된 호출/데이터 가시성, 수명 주기/실패, 호환성 및 구현으로 연기된 결정을 다루세요.

L2는 첫 번째 패키지에서 불완전할 수 있습니다. 중요한 주장을 확립됨, 조건부 또는 열림으로 표시하세요. 모든 열린 선택은 이를 해결할 수 있는 경계가 있는 실험, 증거 임계값 또는 구현 게이트가 필요합니다. 외관을 위해 정밀성을 발명하지 마세요.

references/architecture-contracts.md의 L2 및 상호 작용 형식 규칙을 사용하세요. 패키지에 여러 문서가 포함된 경우 references/document-and-complexity-gates.md의 탐색 및 표준 소유자 확인을 사용하세요.

5단계 — MVP 및 작업 로컬 계약

의도된 경계를 실행하는 가장 작은 실제 폐쇄 루프를 선택하세요. 읽기/수명 주기 폐쇄 슬라이스는 첫 번째 쓰기 경계 슬라이스보다 먼저 올 수 있습니다. 로컬 MVP 레이블은 설명적인 이름과 쌍을 이룰 때만 유지하고, 슬라이스가 증명하는 것과 증명하지 않는 것을 정확히 명시하세요.

경계가 있는 구현 작업을 코딩하기 전에, 해당 작업이 사용하는 L3 계약만 동결하세요. 구현 작업이 채택하거나 개정 사항을 기록할 때까지 후보로 남아 있습니다. 선택되지 않은 모듈에 대한 L3 문서를 만들지 마세요. references/architecture-contracts.md의 L3 및 인터페이스 체크리스트를 사용하세요.

6단계 — 적대적 검토 및 양방향 스틸맨

소유권, 복구, 호환성, 마이그레이션 및 증거 주장을 깨려고 시도하는 적대적 패스를 실행한 다음, 가장 강력한 가치와 의도적으로 보수적인 경계를 명시하는 스틸맨을 따르세요. 패키지를 작성하지 않은 독립적인 검토자를 선호하세요. 그렇지 않으면 새로운 컨텍스트를 사용하고 제한 사항을 공개하세요.

references/adversarial-review.md를 검토 시기, 질문 및 단일 조정 원장에 사용하세요. 모든 발견 사항을 즉시 처리하세요. 차단 발견 사항은 위험이 해결되거나 사용자 또는 독립 검토자에 의해 명시적으로 다운그레이드/예외로 수락될 때까지 게이트를 닫힌 상태로 유지합니다. 거부하거나 연기하는 것만으로는 게이트가 열리지 않습니다.

7단계 — 마이그레이션, 검증 및 프로모션

호환성 계층, 중단 조건, 제거 게이트, 롤백/재시작 경계, 레거시/대상 픽스처 및 동등한 증거를 사용하여 단계별 마이그레이션을 정의하세요. 구현, 호환성 증거 및 리포지토리 권한 업데이트가 함께 병합된 후에만 대상 텍스트를 현재 아키텍처로 프로모션하세요.

각 증분 종료 시, 계속, 명명된 실험 실행, 대상/계약 수정, 또는 중지 및 현재 경로 유지 중 하나의 결과를 선택하세요. 다음 증분은 트리거 및 프로모션 증거가 충족될 때만 시작됩니다. 자세한 증거, 실험 및 ADR 규칙은 references/migration-and-promotion.md를 로드하세요.

8단계 — 인계 및 게시

게시 전:

• 메타데이터, 링크, 카탈로그 및 관련 적합성/회귀 검사를 검증하세요;
• 관련 없는 파일이나 지원되지 않는 구현 주장에 대한 전체 diff를 검사하세요;
• 프로젝트의 기존 변경/인계 기록을 업데이트하세요;
• 오리엔테이션 또는 카탈로그 항목에서 증분 기록을 검색 가능하게 만드세요;
• 정확한 다음 작업과 소유자를 명시하세요.

사용자가 해당 외부 변경을 승인하지 않는 한 PR을 만들거나 브랜치를 푸시하지 마세요. 승인된 경우, 런타임 동작이 실제로 변경되지 않는 한 패키지를 대상 설계/문서로 설명하세요.

선택적 고려 사항

플러그인, 버전 공존, 프로세스 격리, 핫 리플레이스먼트 및 동적 언로딩은 기본 아키텍처 요구 사항이 아닙니다. 요청된 설계가 실제로 이러한 고려 사항 중 하나를 활성화하는 경우에만 references/optional-concerns.md를 로드하세요.

모듈 라우팅

필요 사항	로드
가장 작은 아티팩트 세트 및 전달 지평 선택	deliverable-matrix.md
중요한 사용자 결정 요청 또는 기록	user-decision-gates.md
L1/L2/L3 또는 구현 지향 인터페이스 정의	architecture-contracts.md
문서 성장, 복잡성 또는 과도한 설계 제어	document-and-complexity-gates.md
적대적 검토 및 스틸맨 실행	adversarial-review.md
마이그레이션, 실험, ADR 또는 프로모션 계획	migration-and-promotion.md
플러그인, 격리 또는 버전 공존 설계	optional-concerns.md

모든 모듈을 기본적으로 로드하지 마세요. 활성 단계와 요청된 전달 항목이 필요한 참조 문서를 결정합니다.

수행하지 말아야 할 사항

• 실제 슬라이스 하나를 증명하기 전에 전체 코드베이스를 다시 작성하지 마세요.
• 모든 파일/클래스를 플러그인으로 바꾸지 마세요.
• 명시적인 대상 결정 및 실패 모델 없이 중복 상태 소유자, 스케줄러, 저장소, 버스 또는 수명 주기 권한을 만들지 마세요.
• 이름이 바뀐 통과 래퍼 뒤에 혼합된 책임을 숨기지 마세요.
• 더 낮은 종속성 수만으로 결합 분리를 주장하지 마세요.
• 합성 데모를 기본 MVP 종료 조건으로 사용하지 마세요.
• 확장 정리가 도메인 완료 또는 파괴를 의미한다고 가정하지 마세요.
• 작업 노트, 벤치마크 점수 또는 생성된 산문을 현재 아키텍처 권한으로 취급하지 마세요.