atlasray66-collab/dlm-version-master

DLM Version Master 7 Portable

목적

리포지토리 소유 인프라를 사용하여 .NET 리포지토리 변경 사항을 버전 관리, 검증, 커밋 및 푸시합니다. 제품 이름이나 디렉터리 레이아웃을 가정하지 않습니다. 이 개인 기술은 일반 워크플로를 제공하며, 각 리포지토리는 자체 프로젝트, 릴리스 진입점, 모듈 맵, 출력 경로 및 커밋 정책을 선언합니다.

결과 거버넌스 게이트

버전 상태 변경, 릴리스 빌드, 아티팩트 검증, 스테이징, 커밋 또는 푸시 전에 공유 DLM 결과 거버넌스를 읽고 적용합니다.

• 승인된 범위, 필수 모듈/출력, 내부 버전 결정, 주장과 일치하는 증거 및 중지선을 사용하여 하나의 동결 릴리스/버전 기준선을 설정합니다. dlm-version-master를 직접 호출하면 내부 버전 평가, 필수 빌드/검증, 정확 범위 Git 커밋 및 원격 브랜치로의 푸시가 승인됩니다. 아티팩트 복사, 게시, 태그, 배포 또는 현장 출시는 승인되지 않습니다.
• 소스 해시는 모듈 변경/버전 결정 주장을 지원합니다. 출력 해시는 프로필이 이를 사용할 때 바이트 정체성을 지원합니다. 어느 것도 기준선을 동결하거나 런타임, 조정, 배포 또는 현장 상태를 증명하지 않습니다.
• 프로필에 필요하거나 실질적인 위험 검사만 실행합니다. 녹색 메타데이터는 동작 증거를 대체할 수 없으며, 관련 없는 관리 실패가 조용히 릴리스 기준이 될 수 없습니다.
• 변이 전에 결합된 정체성/범위/사전 스테이지 안전 검사를 한 번 수행한 후 가장 짧은 릴리스 경로를 진행합니다. 실제 소비자나 새로운 실질적 불확실성 없이 영수증, 중복 요약 또는 반복된 전체 검증을 추가하지 마십시오.

권한 및 구성

• dlm-version-master의 모든 직접 호출은 다음에 대한 지속적인 사용자 권한을 수반합니다:
  1. 사용자가 프롬프트에 범프 정책을 명시적으로 지정하지 않는 한 내부 규칙을 통해 버전을 범프할지 여부(없음 vs. 패치 / 마이너 / 메이저)를 자율적으로 결정;
  2. 모듈 버전 또는 빌드 관련 소스 입력이 변경될 때마다 필수 릴리스 빌드 및 바이너리 메타데이터 검증 실행;
  3. 정확히 허용된 경로를 스테이징하고, 필수 사전 커밋 리뷰(ponytail-review)를 실행하고, 수정 범위, 해당 버전, 어떻게 수정했는지, 왜 수정했는지를 포함하는 상세한 구조화된 커밋 메시지로 Git에 커밋하고 원격 리포지토리 브랜치로 푸시(git push).
• 사용자가 현재 턴에 커밋/푸시하지 말라고 명시적으로 지시하거나, 구체적인 안전/검증 게이트가 이를 차단하는 경우(필수 빌드/테스트/리뷰 실패, 대상 파일에 혼합된 관련 없는 변경 사항, 누락/모호한 원격, 또는 분기된 원격 브랜치)에만 직접 호출 시 커밋 또는 푸시를 건너뜁니다.
• 원격 리포지토리 생성, 강제 푸시, 태그, 배포, 게시 및 아티팩트 복사는 별도의 권한으로 유지됩니다.
• dlm-close-release 합성 모드에서는 검색, 내부 버전 결정, 빌드, 체인지로그 및 메타데이터 검증을 수행한 후, 소유 오케스트레이터가 명시적으로 공유 Git 단계를 위임하지 않는 한 정확한 변경 경로를 반환하고 스테이징, 커밋 또는 푸시하지 않습니다.
• 이 개인 기술을 리포지토리에 복사하거나 프로젝트 컨텍스트 매니페스트에서 참조하지 마십시오.
• 엔지니어링, 릴리스 증거, DLM 조정, Git, 배포 및 현장 승인을 별도의 상태로 유지합니다.

시작 컨텍스트

1. 하나의 Git 루트를 확인하고 AGENTS.md를 읽습니다.
2. 리포지토리가 DLM을 사용하는 경우 doc_llm/dlm.json 및 활성 릴리스 작업을 로드합니다.
3. references/versioned-build-contract.md 및 references/git-sync.md를 읽습니다.
4. 편집하기 전에 기존 .sln, .slnx, 실행 파일/라이브러리/플러그인 .csproj, Directory.Build.*, 리포지토리 버전 스크립트, CI/릴리스 정의 및 버전 상태를 검사합니다.
5. 리포지토리 소유 버전 인프라를 우선시합니다. 사용자가 버전 관리 설정을 요청하고 호환 가능한 메커니즘이 없는 경우에만 build/versioning/을 생성합니다.

리포지토리 프로필 확인

다음 순서를 사용합니다:

1. doc_llm/dlm.json 또는 리포지토리 문서에 선언된 릴리스/버전 프로필;
2. 기존 버전/빌드 스크립트 및 버전 상태;
3. 사용자가 지정한 프로젝트/솔루션;
4. 명확한 실행 파일 시작 프로젝트 또는 기본 솔루션;
5. 여전히 모호한 경우 후보를 보고하고 버전 변이 전에 질문합니다.

알려진 제품의 경로를 개인 기술에 포함하지 마십시오. 프로젝트별 동작은 리포지토리 계약 또는 해당 스크립트에 속합니다.

소스 해시 버전 결정 (자율 내부 규칙)

버전을 올릴지 여부와 올릴 수준은 내부 규칙에 의해 자동으로 결정됩니다(사용자가 프롬프트에서 수준을 명시적으로 재정의하지 않는 한). 프로젝트 소유 소스 입력을 해시하고 출력 바이너리는 해시하지 않습니다.

해당되는 경우 포함:

• .cs, .fs, .vb, .xaml, .axaml;
• .csproj, .fsproj, .vbproj, .props, .targets;
• 프로젝트 소유 리소스, 매니페스트, 패키지/프로젝트 참조 및 코드 생성 입력.

제외:

• bin/, obj/, out/, publish/, artifacts/, 스테이징 및 복사된 런타임 출력;
• 생성된 버전 속성, 체인지로그 및 릴리스 노트;
• 모듈의 소스 해시를 계산할 때 버전 상태 자체;
• .pdb, .deps.json, 생성된 DLL/EXE/패키지 출력.

내부 결정 테이블:

• 범프 없음 (없음): 변경되지 않은 모듈 소스 입력 해시는 절대 범프하지 않습니다. 비모듈 파일(예: 문서, DLM 레코드 또는 모듈 해시 입력 외부의 리포지토리 스크립트)만 변경되었거나, 기록된 해시 이후 모듈 소스 입력이 변경되지 않은 경우 버전을 범프하지 말고 빈 버전 변이를 생성하지 마십시오. 범위 내 실제 허용된 변경 사항에 대해 Git 커밋 및 원격 푸시 단계로 직접 진행합니다.
• 모듈 소스 입력 해시가 변경된 경우 자동 범프: 모듈 diff 및 리포지토리 규칙의 의미론적 영향을 검사하여 수준을 자동으로 선택합니다(질문하지 않음):
  • 메이저 / A: 공개 API, 영구 형식, 플러그인 검색, 실행, 권한 부여 또는 배포 계약 변경;
  • 마이너 / B: 하위 호환 기능, 새 모듈/플러그인/도구 또는 기능 추가;
  • 패치 / C: 하위 호환 버그 수정, 레이아웃/접근성/지역화 수정, 리팩터링, 성능 조정, 로깅 또는 내부 유지 관리;
  • 자동: 구성된 경우 리포지토리 선언 기본값, 그렇지 않으면 위의 메이저 / 마이너 / 패치 규칙을 통해 평가(패치 기본값).

바이너리 메타데이터

SDK 스타일 프로젝트의 경우 공개 버전 값이 생성된 출력에 흐르도록 합니다:

<Version>1.2.3</Version>
<AssemblyVersion>1.2.3.0</AssemblyVersion>
<FileVersion>1.2.3.0</FilePath>
<InformationalVersion>1.2.3</InformationalVersion>
<IncludeSourceRevisionInInformationalVersion>false</IncludeSourceRevisionInInformationalVersion>

브랜치, 커밋 SHA, 원격 URL, 작성자/이메일, 커밋 메시지, 머신 경로 또는 리포지토리 경로를 공개 바이너리 버전 필드에 배치하지 마십시오. Git 출처는 Git/CI/릴리스 로그에 속합니다.

빌드 및 검증

내부 규칙이 하나 이상의 모듈을 범프하거나(또는 빌드 관련 모듈 입력이 변경된 경우) 리포지토리 스크립트가 있으면 이를 사용하고, 그렇지 않으면 선택된 범위를 직렬로 빌드합니다:

dotnet build <project-or-solution> -c Release -m:1

잠긴 출력을 강제로 삭제하지 마십시오. 잠금 프로세스를 보고하고 사용자가 안전한 프로세스 종료를 승인하지 않으면 중지합니다.

빌드 후 동결 릴리스 기준선 및 리포지토리 프로필에 필요한 주장만 검증합니다:

1. 영향을 받는 테스트 및 리포지토리 릴리스 검사 실행;
2. 변경된 모든 공개 모듈에 대해 하나 이상의 출력 확인;
3. 적절한 도구를 통해 파일/제품/어셈블리/정보 버전 읽기;
4. 예상 출력 경로 및 필요한 경우 SHA-256/패키지 메타데이터 확인;
5. 변경되지 않은 모듈이 범프되지 않았는지 확인;
6. 릴리스 프로필 또는 실제 릴리스/결정 소비자가 요구하는 경우 리포지토리의 간결한 체인지로그/릴리스 요약 생성.

필수 메타데이터, 테스트, 해싱 또는 출력 정체성을 확인할 수 없는 경우 해당 릴리스 주장은 불완전하여 Git 커밋/푸시 단계를 차단합니다. 관련 없는 기존 또는 관리 실패는 별도로 보고합니다. 실질적 영향을 입증하지 않는 한 준수 출력을 무효화하지 않습니다.

필수 Git 커밋 및 원격 푸시 단계

dlm-version-master의 모든 직접 호출 시 Git 동기화를 따릅니다(사용자가 명시적으로 억제하거나 Git 위임 없이 구성된 하위로 실행 중인 경우 제외):

1. 내부 버전 결정 -> 검증된 빌드(범프되거나 빌드 관련 입력이 변경된 경우) -> 사전 커밋 리뷰(ponytail-review 및 리포지토리 훅) -> 정확 범위 git commit -> 원격 브랜치로의 git push를 실행합니다.
2. dlm-version-master에 의해 생성된 모든 커밋은 실제 git diff --cached 및 버전 전환에 기반한 상세한 구조화된 여러 줄 커밋 메시지를 사용해야 합니다(한 줄 요약 또는 모호한 "버전 범프" / "파일 업데이트"가 아님). 다음 네 가지 필수 섹션을 명시적으로 포함해야 합니다:
   • 수정 범위 (Scope): 변경된 모듈/프로젝트/하위 시스템 및 주요 허용 파일 또는 경계;
   • 해당 버전 (Version): 범프 수준(없음 / 패치 / 마이너 / 메이저) 및 영향받는 각 모듈의 이전 -> 새 버전 전환(또는 모듈이 범프되지 않은 경우 없음 (sourceHash 변경 없음)과 현재 버전);
   • 어떻게 수정했는지 (How): 스테이징된 diff에서 파생된 구체적인 기술 구현(진입점, 데이터/제어 흐름, 알고리즘/UI/구성/빌드 조정);
   • 왜 수정했는지 (Why): 코드 변경 및 버전 결정 모두에 대한 근본 원인, 요구 사항/작업 드라이버, 결함 트리거 또는 아키텍처/호환성 이유.
3. 내부 규칙이 버전을 범프하지 않기로 결정한 경우(변경되지 않은 모듈 소스 해시), 버전 변이를 건너뛰고 빈 버전 커밋을 생성하지 마십시오. 그렇더라도 범위 내 의도된 허용 리포지토리 변경 사항을 스테이징, 리뷰, 커밋(동일한 네 부분 구조화된 커밋 메시지 사용) 및 푸시하거나, 현재 브랜치에 기존의 푸시되지 않은 검증된 커밋을 푸시합니다.

출력

리포지토리 프로필 소스, 동결 릴리스 기준선/중지선, 내부 버전 결정(없음 / 패치 / 마이너 / 메이저) 및 근거, 빌드 범위 및 명령(실행된 경우), 모듈 해시/버전 전환, 변경되지 않은 모듈, 주장 일치 테스트, 검증된 출력 메타데이터/해시, 체인지로그 소비자/경로, 변경된 파일 허용 목록, 전체 구조화된 커밋 메시지(수정 범위 / 해당 버전 / 어떻게 수정했는지 / 왜 수정했는지), 커밋 해시, 검증된 원격 브랜치 푸시 결과 및 차단 vs. 권고 간격을 보고합니다. 더 높은 증거 수준을 빌드 및 Git 동기화 성공과 별도로 유지합니다.