DLM 마감 및 릴리스 오케스트레이션

DLM 마감 및 릴리스 7 Portable

목적

검증된 엔지니어링 범위를 작업 완료, 지식 침전, 릴리스 생성, 버전 관리, Git 커밋, 또는 배포와 혼동하지 않고 마감합니다. 이 개인 스킬은 수명 주기를 조율하며, 저장소 계약과 하위 스킬은 자체 기술 규칙을 유지합니다.

결과 거버넌스 게이트

어떤 마감 쓰기, 릴리스/버전 변형, 공식 감사, 스테이징, 또는 커밋 전에 공유 DLM 결과 거버넌스를 읽고 적용하십시오.

• 엔지니어링 목표 상태, 증거 상태, DLM 조정 상태, 릴리스 상태, Git 상태, 배포 상태, 현장 승인 상태를 분리하십시오. 하나를 진행한다고 다른 것이 암시되지는 않습니다.
• 승인된 모드에 대해 하나의 수용 기준 기준선을 해결하십시오. 마감 쓰기 또는 릴리스/Git 변형 전에, 기준선 소유자는 한 번만 대상, 비목표, 승인된 범위, 필수 증거, 기준, 중지 선을 동결합니다. 해시, BOM/EOL, 체크아웃 표현, 영수증은 이를 동결하거나 무효화하지 않습니다.
• 마감/침전/릴리스 기록은 해당 계약/결정에 의해 요청되거나 소비될 때만 대상 작업입니다. 순수한 관리적 변경은 관련 없는 빌드/테스트/감사를 다시 열지 않습니다.
• 안정적인 목표 상태에 대해 최대 한 번의 공식 전체 감사를 사용하며, 사용자, 수락된 계약, 또는 중대한 위험이 정당화할 때만 사용합니다. 수리 후, 실패한 조건과 직접적인 회귀만 재검증합니다.

가장 좁은 승인 모드 선택

모드	허용된 작업	일반적인 의도
close-only	마감 검토, 침전, DLM 검증	"작업 마감", "완료 침전"
release-verify	close-only + 저장소 릴리스/버전 빌드 및 아티팩트 메타데이터 검증	"릴리스 준비", "릴리스 버전 검증"
release-commit	release-verify + 정확한 경로 스테이징 및 커밋	"버전 업데이트 및 Git 커밋"

기본값은 close-only입니다. 커밋 요청이 push, tag, deploy, publish, 또는 artifact copy를 승인하지는 않습니다. 각각은 별도로 승인됩니다. Git/버전 변형을 구분할 수 있을 만큼 표현이 충분하지 않으면 중지하고 물어보십시오.

저장소 및 계약 잠금

1. 하나의 Git 루트를 결정하고 AGENTS.md 및 DLM 계약을 읽습니다.
2. 작업 및 릴리스 프로필에 필요한 최소한의 dlm-load를 실행합니다.
3. 이 개인 스킬을 저장소에 복사하거나 컨텍스트 매니페스트에 추가하지 마십시오.
4. 저장소에서 선언한 릴리스 프로필을 사용합니다:
   • none: 사용자가 절차를 제공하지 않으면 마감만;
   • dotnet: 합성 모드에서 dlm-version-master 사용;
   • custom: 저장소 소유 버전/빌드/검증 계약 사용.
5. 다중 저장소 또는 서브모듈 작업에서는 각 Git 루트에 대해 별도의 허용 목록, 검증 결과, 커밋을 사용하십시오. 저장소 간 원자성을 주장하지 마십시오.

0단계 — 범위 스냅샷

쓰기 전에 이 결합된 작성자/범위 안전 스냅샷을 한 번 수행하십시오:

git status --short
git diff --name-status
git diff --cached --name-status
git ls-files --others --exclude-standard

작업 소유 후보, 기존의 관련 없는 변경 사항, 사전 스테이징된 파일에 대한 정확한 집합을 구축하십시오. 사용자 의도, 동결된 승인된 범위, 작업 문서, diff에서 소유권을 설정할 수 없으면 변형 전에 중지하십시오. 단순히 승인 증거를 생성하기 위해 스냅샷을 반복하지 마십시오. 절대 git add . 또는 git add -A를 사용하지 마십시오.

1단계 — 마감 검토

동결된 기준과 일치하는 증거에 대해 대상 마감 검토를 수행하십시오. dlm-reflect를 사용하십시오. 공식적인 독립 검토는 사용자가 요청하거나, 수락된 계약이 요구하거나, 중대한 위험이 정당화하지 않으면 선택 사항입니다. 선언된 완료 수준이 입증되면 계속 진행하고, 그렇지 않으면 중대한 남은 격차를 현재 범위 작업/차단으로 라우팅하십시오. 빌드 성공만으로는 동작, UI, 하드웨어, 마이그레이션, 안전성, 또는 현장 증거가 되지 않습니다. 마찬가지로, 오래된 관리 인덱스만으로는 입증된 동작을 반증하지 않습니다.

2단계 — 침전

사용자가 침전을 요청했거나, 수락된 저장소/작업 계약이 요구하거나, 실제 로딩/릴리스/결정 소비자가 동기화를 필요로 하는 경우, 합성 모드에서 dlm-sediment를 한 번 실행하십시오. 확인된 작업/도메인 지식과 상태만 기록하십시오. BRIEF/L0 승인 게이트는 계속 활성 상태입니다. 하위 스킬은 정확한 변경 경로를 반환해야 하며 스테이징하거나 커밋해서는 안 됩니다. 그러한 트리거가 없으면 sediment: not required를 기록하고 확인된 엔지니어링 결론을 보존하십시오.

실제 작업/지식 소비자에 대해 한 번 동기화하고 기존 증거를 재사용하십시오. 조정 레코드만 변경되었기 때문에 동의어 영수증을 만들거나 관련 없는 엔지니어링 검증을 다시 실행하지 마십시오.

close-only의 경우, 승인된 마감에 DLM 상태가 포함되거나 현재 계약/소비자 클레임이 이에 의존하는 경우에만 DLM 상태 확인을 실행한 다음 마감 보고서 후 중지하십시오. 적용 가능하지 않은 확인을 건너뛰는 것은 실패가 아닙니다.

3단계 — 릴리스 검증

릴리스 모드에만 해당:

1. 저장소 릴리스 프로필과 정확한 출력 범위를 결정합니다.
2. 버전 의도를 결정합니다. Major/Minor는 명시적 의도가 필요합니다. Patch/Auto는 릴리스 의도가 존재하고 저장소 계약이 해당 기본값을 선언하는 경우에만 허용됩니다.
3. 저장소 계약이 달리 지정하지 않는 한 저장소 버전/빌드 프로세스를 직렬로 실행합니다.
4. 테스트를 실행하고 동결된 릴리스 기준/프로필에서 요구하는 공개 바이너리/패키지 메타데이터 및 해시를 검증합니다. 검토자 선호도 확인을 새로운 릴리스 조건으로 추가하지 마십시오.
5. 의도적인 버전 상태, 변경 로그, 릴리스 인프라, 작업 소유 소스 파일만 후보 허용 목록에 추가합니다.

빌드, 테스트, 해시, 또는 메타데이터 실패는 해당 확인이 동결된 릴리스 기준선, 저장소 프로필, 또는 입증된 중대한 출력 위험에 의해 요구되는 경우 커밋/릴리스 주장을 차단합니다. 관련 없는 기존 또는 관리적 실패는 별도로 보고되며 릴리스 기준을 조용히 확장하지 않습니다.

4단계 — 정확한 스테이징 집합 게이트

release-commit에만 해당:

• 허용 목록을 저장소 상대 정확한 경로로 정규화합니다.
• 현재 스테이징된 파일을 사전 스테이징된 스냅샷과 비교합니다.
• 사용자 작업을 언스테이징하지 마십시오. 사전 스테이징된 파일이 허용 목록 밖에 있으면 중지하고 보고합니다.
• 허용 목록에 있는 파일이 안전하게 분할할 수 없는 관련 없는 기존 변경 사항을 혼합하면 중지하고 물어보십시오.
• 비밀, 머신 로컬 구성, bin/, obj/, out/, 로그, 캡처, 게시/스테이징 출력, 임시 아티팩트를 명시적으로 요청되고 적절하지 않은 한 제외합니다.
• 저장소에서 요구하는 공백/인코딩 확인을 실행합니다.

5단계 — 스테이징 및 커밋

git add -- <exact-paths>
git diff --cached --name-status
git diff --cached --stat
git diff --cached --check
git status --short

스테이징된 경로와 승인된 허용 목록 간의 정확한 일치를 요구합니다. 커밋 전에, 전역 AGENTS.md(ponytail-review 게이트 및 가드 마커)와 저장소에서 요구하는 커밋 전 검토를 이 정확한 스테이징된 diff에 대해 실행하십시오. 해당 규칙이 요구하는 대로 각 소견을 해결하거나 명시적으로 유지하십시오. 필수 검토 스킬 또는 훅을 사용할 수 없으면 우회하는 대신 커밋하기 전에 중지하고 그 격차를 보고하십시오. 각 Git 루트에 대해 저장소 관례를 사용하여 한 번 커밋하십시오. 요청되지 않으면 수정(amend)하지 마십시오. 커밋 후 git show --stat --oneline HEAD와 나머지 작업 트리를 검사하십시오.

실패 규칙

• 0이 아닌 하위 명령은 현재 동결된 기준, 적용 가능한 계약, 접촉된 아티팩트 무결성 검사, 또는 중대한 안전/릴리스 경계를 실패할 때만 이후 단계를 차단합니다. 관련 없는 기존 및 관리적 실패는 새로운 게이트가 되지 않고 보고됩니다.
• 차단된 작업은 마감되지 않습니다. 그 이유, 소유자, 시도, 릴리스 조건을 유지하십시오.
• 취소된 작업은 성공적인 릴리스인 척하지 않고 취소 상태를 유지할 수 있습니다.
• 출력 잠금은 강제 삭제되지 않고 보고됩니다.
• 관련 없는 작업은 그대로 유지됩니다.
• 기준선 무효화는 새로운 SSOT 충돌, 잘못된 전제, 안전성, 또는 데이터 손실 위험을 위해 예약됩니다. EOL/BOM, clean/smudge, 타임스탬프, 표시 순서, 또는 영수증 전용 변경은 전체 검증을 무효화하거나 다시 열지 않습니다.

최종 보고서

모드, 저장소/프로젝트 ID, 수용 기준 기준선 상태/소유자/중지 선, 마감 검토 유형/평결, 침전 소비자/경로, DLM 확인, 릴리스 프로필 및 버전 변경 사항, 일치하는 확인된 아티팩트, 스테이징된 허용 목록, 커밋 해시(있는 경우), 차단 대 권고 격차, 고의로 건드리지 않은 관련 없는 파일을 보고하십시오. 커밋/push/태그/배포/아티팩트 복사 중 어떤 것이 수행되지 않았는지 명시적으로 진술하십시오. 승인된 모드 경계에서 중지하십시오. 다음 하위 작업, 작업 항목, 지연된 발견, push, 태그, 또는 배포를 자동으로 활성화하지 마십시오.