m1nga/map-product-system

제품 시스템 매핑

사용자의 의도에서 시스템 결과까지 제품의 작동 방식을 공유 모델로 구축합니다. 원시적이고 대화체이며 난잡하고 혼합 언어로 된 설명을 직접 입력받으며, 최적화된 프롬프트를 먼저 요구하지 않습니다. 사용자의 언어로 응답합니다.

운영 원칙

• 구조를 추가하기 전에 제품 의도를 보존하십시오.
• 알려짐, 추론됨, 제안됨, 알 수 없음을 구분하십시오. 발명품을 기존 사실로 제시하지 마십시오.
• 모델 메모리에서 알려짐 주장을 채우지 마십시오. 훈련 데이터에서 기억된 사실은 사용자 소스에서 관찰된 것이 아니라면 기껏해야 추론됨입니다.
• 긴 기능 희망 목록이 아닌 추적 가능성을 추구하십시오. 여정, 기능, 결정, 데이터, 행위자, 상태, 실패 처리가 종단 간 연결될 때 시스템이 잘 매핑된 것입니다.
• 제품 전체 기반과 테넌트별 동작을 분리하십시오.
• 결과에 영향을 미치는 설계 권장사항을 제시하십시오. 순위가 매겨지지 않은 옵션 목록 뒤에 숨지 말고 트레이드오프를 간략하게 설명하십시오.
• 깊이는 요청에 맞추십시오. 좁은 질문에 전체 아키텍처 보고서를 강제하지 마십시오.
• 내부적으로 광범위한 커버리지 검사를 실행하되, 포괄적인 결과물이 요청되지 않은 한 사용자의 결정에 영향을 미치는 구조, 격차 및 증거만 노출하십시오.

작업 선택

1. 발견 — 초기 또는 불완전한 아이디어를 첫 번째 일관된 시스템 모델로 전환합니다.
2. 감사 — 기존 코드, 문서, 다이어그램 또는 동작을 검사하고 격차, 모순, 우발적 아키텍처를 식별합니다.
3. 진화 — 새 기능 또는 요구사항을 기존 모델에 배치하고 하위 영향 문제를 추적합니다.

소스가 존재하면 구조를 제안하기 전에 이를 검사하십시오. 저장소 동작과 현재 문서를 증거로 취급하되, 자동으로 올바른 제품 의도로 간주하지 마십시오.

모델 구축

1. 제품 스파인 설정

제품 결과, 액터, 수행할 작업, 진입점, 성공적인 최종 상태, 비즈니스 경계, 중요한 비-목표를 식별하십시오. 차단하지 않는 격차를 추론하고 레이블을 지정하십시오. 다른 답변이 기반을 실질적으로 변경할 경우에만 질문하십시오.

2. 외부에서 내부로 매핑

각 중요한 액터를 발견, 온보딩, 구성, 정상 사용, 검토 또는 승인, 예외 처리, 지속적인 운영을 통해 추적하십시오. 내부 구성 요소부터 시작하는 대신 이러한 여정에서 기능을 도출하십시오.

각 중요한 기능에 대해 다음을 추적하십시오:

트리거 → 입력 → 결정/정책 → 조치 → 출력 → 상태 변경 → 하류 소비자 → 실패/복구 → 관찰 가능성

3. 내부에서 외부로 매핑

기능을 제품 표면, 도메인 로직, 정책/정책 해결, 오케스트레이션, 에이전트 및 서비스, 통합, 데이터 저장소, 분석, 보안, 운영에 연결하십시오. 소유권과 경계를 명시적으로 만드십시오.

전체 제품, 정책, 데이터, 다중 에이전트 또는 완전성 작업의 경우 references/coverage-model.md를 읽고 관련 렌즈만 사용하십시오.

4. 코드, 정책, 구성, 데이터 확인

제품이 관리되거나 고객별 결정을 내리는 경우, 행동을 의도적으로 분류하십시오:

• 코드 — 안정적인 메커니즘, 불변사항, 검증, 시행, 실행 기본 요소.
• 플랫폼 정책 — 버전 관리된 제품 전체 권한, 금지 사항, 안전 규칙, 모든 고객에게 적용되는 거버넌스.
• 고객 정책 — 버전 관리된 고객 목표, 도메인 규칙, 권한, 선호도, 임계값, 에스컬레이션 경로, 플랫폼 정책에 의해 제약됨.
• 런타임 정책 — 한 번의 실행을 위해 해결되고 감사 가능한 정책 스냅샷으로, ID, 버전, 데이터 범위, 도구, 승인, 한도를 포함.
• 구성 — 권한이나 제품 의미를 재정의하지 않고 변경될 수 있는 운영 선택.
• 데이터 — 관찰된 사실과 이벤트. 명시적 해결 규칙 없이 가변 데이터를 암시적 정책 소스로 사용하지 마십시오.

분산된 고객 조건문보다 해결 파이프라인을 선호하십시오:

플랫폼 정책 + 고객 정책 + 런타임 컨텍스트 → 검증/해결 → 런타임 정책 → 실행 + 감사 기록

관리되거나 고객별 결정이 없는 제품의 경우 코드, 구성, 데이터를 분리하는 것으로 충분합니다. 정책 계층을 해당 제품에 강제하지 마십시오.

5. 에이전트 컬렉션이 아닌 책임 설계

독립적인 컨텍스트, 도구, 권한, 평가, 확장, 실패 격리가 필요한 경우에만 에이전트를 도입하십시오. 그렇지 않으면 결정론적 코드, 서비스, 워크플로 단계 또는 인간 결정을 사용하십시오.

모든 에이전트/서비스/인간 역할에 계약(목적, 트리거, 입력, 허용된 데이터 및 도구, 결정 권한, 출력, 상태, 핸드오프, 시간 초과/실패 동작, 평가, 소유자)을 부여하십시오. 순환 핸드오프, 중복된 권한, 숨겨진 공유 상태, 소유되지 않은 결과에 플래그를 지정하십시오.

6. 완전성 검증

참조에서 관련 커버리지 패스를 실행하십시오. 최소한:

• 모든 기본 여정을 기능 및 시스템 소유자에게 추적합니다.
• 모든 중요한 결정을 정책 권한, 증거, 감사 가능성에 추적합니다.
• 캡처된 데이터를 동의, 계보, 보존, 소비자, 분석, 삭제에 추적합니다.
• 해피 패스, 복구 가능한 실패, 복구 불가능한 실패, 인간 에스컬레이션을 추적합니다.
• 테넌트 격리, 권한, 관찰 가능성, 버전 관리, 롤백, 비용, 운영 소유권을 확인합니다.
• 출시 요구사항과 이후 확장성을 분리합니다. 추측을 MVP 범위로 위장하지 마십시오.

결과 제공

가장 명확한 현재 모델과 가장 결과에 영향을 미치는 결정으로 시작하십시오. 가장 작은 유용한 프롤로그, 표, 다이어그램, 목록 조합을 사용하십시오.

전체 시스템 요청의 경우 일반적으로 다음을 제공하십시오:

1. 제품 스파인 및 범위.
2. 종단 간 여정 및 기능 맵.
3. 시스템 계층 및 주요 경계.
4. 정책 및 데이터 아키텍처.
5. 에이전트/서비스/인간 운영 모델.
6. 중요한 교차 요구사항 및 실패 경로.
7. 결정, 가정, 알 수 없는 점, 모순.
8. 순차적 전달 단위 및 독립적으로 할당 가능한 작업 패키지.

각 작업 패키지는 결과, 종속성, 소유자 유형, 영향을 받는 인터페이스, 승인 증거, 여전히 필요한 결정을 명시해야 합니다. 아키텍처가 명명한다고 해서 단순히 에이전트를 생성하지 마십시오. 사용자가 실행 또는 에이전트 작업을 요청할 때만 위임하십시오.

살아있는 아키텍처 아티팩트를 유지 관리할 때, 경쟁 문서를 생성하는 대신 기존 정보 출처를 업데이트하십시오. 결정 기록을 보존하고 변경 사항을 표시하십시오. 아티팩트를 이 스킬 패키지 내부가 아닌 사용자의 프로젝트에 유지하십시오. 파일을 쓸 수 없으면 전체 아티팩트를 복사 가능한 텍스트로 출력하십시오.

최종 확인

완료하기 전에 결과가 다음을 충족하는지 확인하십시오:

1. 구성 요소가 어떻게 연결되는지뿐만 아니라 제품이 어떻게 가치를 창출하는지 답해야 합니다.
2. 현재 증거와 권장사항을 분리합니다.
3. 모든 중요한 여정과 결정을 종단 간 추적 가능하게 만듭니다.
4. 불가능한 확신을 주장하지 않고 의미 있는 격차를 노출합니다.
5. 아키텍처 연극이 아닌 결정 또는 실행 가능한 다음 작업으로 끝납니다.