v0.3.0

DVA v0.3.0

v0.3.0은 plan 선언의 재사용 범위와 native 실행의 안전한 경계를 넓히고, 실행 전 입력과
종료 상태를 더 엄격하게 확인합니다.

선언과 계획

• **plan alias와 단일 부모 extends**를 지원합니다. alias는 대상 plan만 가리켜야 하며
  description 외의 필드와 함께 쓸 수 없습니다. alias 체인은 최대 10단계까지 허용하며, 순환·자기참조·미정의 참조와 깊이 초과는 거부됩니다.
  extends는 단일 부모와 최대 3단계만 허용하고, composes: plan에는 적용할 수 없습니다.
  자식은 scalar를 덮고 vars는 키별로 합치며, 같은 이름의 entries는 서비스 합집합이 아니라
  자식 선언으로 교체합니다.
• stack 엔트리에 **optional·primary**를, native runner에 **post_build**를 추가했습니다.
  optional은 선언한 디렉터리가 없을 때 해당 엔트리만 plan에서 빼고, 다른 런타임 실패를 숨기지
  않습니다. primary는 대표 엔트리를 명시하며, post_build는 build 성공 뒤 같은 dir/env에서
  실행되고 실패하면 build도 실패합니다.
• interaction hook의 plans: 필터가 지정한 plan에서만 hook을 실행합니다. 필터가 없으면 기존처럼
  모든 plan에 적용됩니다.
• drift_ignore와 suggestions: {makefile, package_json}로 자동 탐지·제안 억제를 선언할 수
  있습니다. 선언됐지만 없는 파일이나 서비스를 참조하는 interaction은 억제 대상이 아닙니다.
• interaction.destructive: true는 하위 명령에 상속되며, dva agent-deny install --scope project가
  해당 interaction의 deny 패턴을 투영합니다. 하위 명령은 destructive: false로 해제할 수
  있습니다.

실행 안전성

• composition plan의 native readiness 대기는 health check의 가장 큰 ready_timeout(미지정 시
  30초)으로 제한됩니다. native 프로세스가 시작 직후 끝나면 PID와 log 경로를 포함해 빠르게
  실패하며, 무한 대기하지 않습니다.
• required env_file 입력이 없거나 잘못됐을 때 dva run은 실행·--dry-run 미리보기·파괴적
  명령 확인보다 먼저 실패합니다. import/direct-child route도 명령 소유자의 입력만 판정합니다.
• native process의 stop/down은 SIGTERM 뒤 최대 5초 동안 종료를 기다립니다. 취소·시간 초과
  또는 종료 실패에는 PID/log 파일을 남겨 살아 있는 프로세스를 새 실행이 덮어쓰지 않게 합니다.
• config module/override 병합은 typed runner 설정을 필드 단위로 deep merge하여 native 환경과
  runner별 설정을 보존합니다.

CI profile 의존성

CI profile은 이미 ci.profiles.<name>.steps 배열로 선언합니다. depends_on은 profile이나
ci 아래가 아니라 각 step 항목에 둡니다.

ci:
  profiles:
    commit:
      steps:
        - name: test
          run: go test ./...
        - name: lint
          run: go vet ./...
          depends_on: [test]

이 구조에서 lint는 test가 성공한 뒤 실행됩니다. step 이름은 같은 profile 안에서 유일해야
하며 의존 대상도 그 profile의 step이어야 합니다.

확인할 점

• alias/extends, optional native entry, destructive interaction을 쓰는 config는 먼저
  dva config validate로 확인하세요.
• process 종료가 timeout으로 실패하면 PID/log를 지우거나 새 up을 시도하기 전에 해당 프로세스의
  실제 상태를 확인하세요.
• 기존 CI profile 문법은 이 릴리스에서 새로 도입된 것이 아닙니다. 의존성을 추가할 때에는 위처럼
  step 아래에 배치하세요.

v0.2.0

DVA v0.2.0

v0.2.0은 v0.1.48 이후 130여 개 커밋을 담은 첫 minor입니다. 이 저장소는 0.1.44부터
0.1.48까지 patch만 올려 왔지만, 이번에는 어제까지 통과하던 config를 거부하거나 같은
명령을 다르게 실행하는 변경이 10건이라 번호가 그 신호를 싣습니다. 0.x에서 SemVer는
patch로 breaking을 내는 것도 허용하지만, 그러면 0.1.47→0.1.48과 0.1.48→0.1.49가 똑같은
크기의 사건으로 보이면서 후자만 config를 거부합니다.

이 노트가 왜 CHANGELOG보다 긴가. 태그를 자르기 직전에 v0.1.48..HEAD를
커밋 단위로 다시 훑었더니, CHANGELOG에 기록을 남긴 커밋은 4개뿐이었습니다. 나머지에서
사용자에게 보이는 변경 24건이 나왔고, 아래 breaking 10건 중 7건이 그 과정에서 처음
드러났습니다. 8건만 보고 게시했다면 이 노트가 조용히 틀린 채로 굳었을 것입니다.

Breaking — 넘어가기 전에 확인하세요

한 문장 요약: Validate()만 보면 안 됩니다. 10건 중 4건(아래 §2의 셋과 §4)은
validate를 한 번도 돌리지 않는 사용자에게도 발생하고, 그중 하나는 데이터를 지웁니다.

1. config가 거부됩니다 (dva config validate exit 1, 플래그 불필요)

• ci, secret, job이 예약어가 됐습니다. 이 세 이름을 interaction 키
  (ci:build 같은 namespace 접두사 포함)나 subproject 이름으로 쓰고 있었다면 지금 바로
  깨집니다. up·manifest와 달리 실제로 쓰고 있었을 법한 흔한 단어이므로, 이 릴리스에서
  가장 부딪히기 쉬운 항목입니다. 같은 이유로 kubectl도 예약어입니다.
• 내장 커맨드와 같은 이름의 subproject를 거부합니다 (TASK-263 §3). subprojects.up은
  dva up:web이 자식의 web으로 라우팅되게 만드는데, 같은 철자를 interaction 키로도 쓰면
  한 철자가 두 의미를 갖습니다. 더불어 자식 자신의 validator가 거부하는 키는 부모의 세
  주소 형태(--project, p:key, p/key import) 전부에서 거부됩니다 — 이전에는 부모를
  통해서만 실행되어 "어느 validator가 권위인가"가 서 있는 위치에 따라 달라졌습니다.
• root라는 이름의 subproject를 거부합니다 (TASK-333). root는 아래 owner 필드가
  "이 dva.yml이 직접 선언한 항목"을 가리키는 값입니다. 같은 이름의 subproject가 있으면
  로컬 항목과 그 subproject에서 import한 항목이 같은 owner를 보고하고, 이 필드로 필터링하는
  소비자에게는 구별할 두 번째 신호가 없습니다. root/web 라우팅 자체는 그대로입니다.
• interaction의 env_file:을 schema가 거부합니다 (TASK-266 Stage B).
  interaction.<name>.env_file과 subcommands.*.env_file은 additional-property 오류이며,
  최상위 env_file:과 커맨드 environment:로 옮기라는 path-scoped 안내가 붙습니다.
  0.1.48이 내던 semantic 경고는 도달 불가가 되어 제거했습니다.

2. 실행이 달라집니다 (validate를 거치지 않아도 발생)

• dva down <plan> --purge가 compose 프로젝트 전체를 내립니다 — 파괴적입니다.
  서비스를 고르는 plan은 이전에 compose rm으로 내려서 named volume과 프로젝트 네트워크에
  닿지 못했습니다. --purge는 이제 선택된 서비스와 무관하게
  compose down --remove-orphans --volumes --rmi local을 돌립니다 — plan이 고르지 않은
  서비스의 named volume, 프로젝트 네트워크, orphan 컨테이너, 로컬 빌드 이미지가 함께
  삭제됩니다. 스크립트에 dva down <plan> --purge --force를 걸어 두었다면 올리기 전에
  확인하세요. 평범한 down과 --volumes는 plan이 서비스를 고를 때만 그 범위를
  유지합니다 — 고르지 않는 plan에서는 이전부터 프로젝트 전역이었고, 그건 바뀌지
  않았습니다.
• interaction.<name>.workdir이 로컬 러너에서도 적용됩니다. 이 필드는 그동안 compose
  러너의 컨테이너 --workdir으로만 쓰였고 호스트 실행에서는 조용히 무시됐습니다. 없는
  디렉토리를 적어 두었다면 이제 workdir "sub": directory not found (resolved to …)로
  실패합니다. 스크립트가 자기 cd를 하고 있었다면 시작 디렉토리가 달라집니다.
• ${VAR:-default}가 POSIX 의미대로 확장됩니다. 이전 확장기는 닫는 중괄호를 선택적으로
  취급해서, 변수가 설정돼 있을 때 ${POSTGRES_USER:-gorisa}가 gorisa:-gorisa}로
  확장됐습니다. 이전 출력이 깨진 문자열이었으므로 실무 위험은 낮지만, 같은 config가 다른
  문자열을 만듭니다.

3. --strict에서만 exit 1이 됩니다 (CI에 --strict를 걸었다면)

• 참조 무결성 경고 6종: plan이 선언하지 않은 서비스, 참조되지 않는 environment/site,
  아무것도 바꾸지 않는 entry override, 빈 interaction command, 제거된 CLI를 가리키는 문자열,
  고아 health check. 이 규칙을 도입한 커밋 자체가 이 저장소 examples/ 4개에서 실제로 죽은
  config를 찾아냈습니다 — 오탐만 만드는 규칙이 아닙니다.
• 미등록 compose 파일 경고: compose-*·docker-compose-* 접두사가 autodiscovery에
  들어가고 include:로 도달하는 디렉토리까지 훑습니다. 등록된 파일 옆의 compose-foo.yml이
  없던 경고를 만듭니다.

4. exit code가 바뀝니다

• dva init --recursive가 "이미 있음"을 진척으로 세지 않습니다: 남아 있던
  webui/dva.yml 하나가 쓸 수 없는 루트를 성공으로 보고하던 동작을 고쳤습니다. 부분적으로
  scaffold된 트리에 이 명령을 건 CI 단계는 exit 0 → exit 1입니다.

새 커맨드와 새 config 섹션

• dva ci [profile] — 로컬 CI 프로파일 실행기. 최상위 ci.profiles.<name>
  (steps[], depends_on, max_parallel 1–32, timeout, warn_after, locks[]).
  dva ci status, dva ci logs <run-id>, 전역 --dry-run이 해석된 프로파일을 JSON으로
  출력합니다. 자세히: docs/53-ci-profiles.md.
• dva secret push <target> — 최상위 secrets.sources.<name>.sops와
  secrets.targets.<name>. 자세히: docs/62-remote-artifact-jobs.md.
• dva job run|status|resume|verify — 최상위 jobs.<name>(provider, repository,
  ref, timeout, inputs, secret_targets, runs[]). 자세히: 같은 문서.
• plans.<plan>.entries[].profiles — compose --profile을 선언 순서대로 넘깁니다.
  dva build/dva logs에도 전달됩니다.
• dva config migrate --write가 최상위 섹션을 정규 순서로 재배치합니다. 이 기능과 그
  손상 사례들(들여쓴 #이 스크립트 마지막 줄을 먹던 것, 중복 키 panic, ... 종결자,
  빈 줄 구분자 이동, EOF 주석 상승, CRLF·단독 CR)이 모두 같은 릴리스에 들어 있습니다.
  쓰기 전에 커밋해 두세요.

이번 릴리스에서 열리는 것

• import된 항목이 출처와 canonical 주소를 밝힙니다 (TASK-333): dva manifest와
  dva ls --json의 모든 항목에 owner가 실립니다. as: alias를 준 import는 canonical
  항목에 aliases가, alias 항목에 alias_of가 붙습니다. plans: import는 아직 이 세
  필드를 싣지 않습니다.
• dva kubectl이 kubectl 패스스루의 canonical 이름입니다 (TASK-255/TASK-256).
• dva run --project가 subproject 이름을 완성합니다 (TASK-333).
• subproject 하나를 로드하지 못해도 나머지의 p:key completion이 남습니다 (TASK-333).
• 부모의 exclude_tags가 자식의 거부보다 먼저 판정합니다.
• dva config validate가 hard error를 전부 모아 한 번에 실패합니다 — legacy config를
  한 번에 하나씩 고칠 필요가 없어집니다.
• 그 밖의 수정(dva logs/dva build의 plan 범위, --dry-run up의 health 대기, 중복 plan
  오탐, config env seal의 원자적 create-only, Makefile 커버리지 매칭)은 CHANGELOG의
  ## [0.2.0] §Fixed에 있습니다.

문서 — 틀렸던 것을 철회했습니다

CHANGELOG ## [0.2.0] §Documentation에 전체 목록이 있습니다. 새 설명이 아니라 이전
문서가 사실과 달랐던 부분의 취소이므로, 그 문장에 기대어 config를 쓴 적이 있다면 읽어
보세요. 요지: interaction.runner:의 알 수 없는 값은 거부되지 않고 compose 러너로
폴백하며, script_file:의 컨테이너 내 실행 보장은 없고, endpoints.source는 compose
파일을 읽지 않으며, endpoints.tags는 CLI 플래그로 좁혀지지 않고, exclude_tags는
compose 태그를 거르지 않습니다.

호환성

• MinScaffoldVersion은 0.1.44로 유지됩니다. 이 상수가 묻는 것은 "이 릴리스가 무엇을
  깨뜨렸는가"가 아니라 **"dva init이 이제 예전 DVA가 파싱할 수 없는 것을 내보내기
  시작했는가"**입니다. 위 breaking 중 일부는 Validate() 밖에 있지만, scaffold가 내보내는
  key 집합은 0.1.44 이후 늘지 않았습니다(v0.1.48..HEAD의 init_scaffold.go diff에서
  새로 나온 YAML 키 없음 — 바뀐 것은 어떤 템플릿을 고르는지이지 어떤 문법을 쓰는지가
  아닙니다). 올리면 새로 만든 모든 config가 그보다 오래된 DVA 전부에서 로드를 거부하게
  되고, 되돌리면 이미 배포된 config가 깨집니다.
• env_bridge:가 요구하는 version: 하한은 계속 0.1.48입니다. 릴리스 번호와 같은
  철자를 쓰지만 다른 값이며, 올리면 오늘 유효한 사용자 config가 내일 거부됩니다.
• dva manifest의 schema_version은 1.5 → 1.8입니다(전부 추가 전용). 1.5 → 1.6은
  ci_profiles와 ci 커맨드 항목, 1.6 → 1.7은 항목별 owner·aliases·alias_of,
  1.7 → 1.8은 secret_targets·jobs와 커맨드 항목의 새 effects입니다. 1.7을 핀한
  소비자는 이 릴리스의 바이너리에서 깨집니다.
• dva ktl은 dva kubectl을 가리키는 visible compatibility 이름으로 남습니다. 이
  릴리스에서 deprecate하거나 제거하지 않습니다.
• dva validate는 dva config validate의 visible compatibility route입니다.
• 공개는 여전히 CI가 아닌 승인된 수동 절차입니다. 이미 공개된 tag는 이동하거나 다시
  만들지 않습니다.

v0.1.48

DVA v0.1.48

v0.1.48은 0.1.47 이후 command-surface 계약과 runtime 수정을 공개하는 minor입니다.
실행 모델의 큰 골격(stack 선언, named plans)은 그대로입니다. MinScaffoldVersion은
0.1.44로 유지됩니다. kubectl top-level 승격은 이 릴리스에 포함하지 않습니다.

이번 릴리스에서 열리는 것

• dva config env 브리지(unseal/edit)와 게이트된 seal/show. env_bridge:를
  쓰려면 그 config의 version:이 0.1.48 이상이어야 합니다. 섹션을 생략한 기존
  config는 한 글자도 바뀌지 않습니다.
• 검증된 capability만 쓰는 dva init. 고정 3-plan 템플릿은 생성하지 않습니다.
• root가 child의 exposed plan을 composes:로 모으는 교차 프로젝트 composition.
• interaction env_file: Stage A 폐기 예고. dva config validate가 semantic 경고를
  내고, --strict는 그 경고만으로도 exit 1이 됩니다. 필드는 0.1.49에서 거부됩니다.

호환성

• dva init이 쓰는 version:은 계속 0.1.44입니다.
• dva validate는 dva config validate의 visible compatibility route입니다.
• ktl 경로는 이 릴리스에서 바뀌지 않습니다.
• 공개는 여전히 CI가 아닌 승인된 수동 절차입니다. 이미 공개된 tag는 이동하거나 다시
  만들지 않습니다.

v0.1.47

DVA v0.1.47

v0.1.47은 수동 공개 릴리스 절차를 더 엄격하게 검증하는 패치 릴리스입니다. DVA의 실행
모델이나 dva.yml 호환성은 변경하지 않습니다.

공개 안전성

• 공개 전 검사는 clean detached worktree, immutable tag·commit·runtime version, 검토된
  release notes SHA-256, GoReleaser pin, remote tag/Release 부재와 비영속 GitHub write-capability를
  모두 확인합니다. 어느 하나라도 확인할 수 없으면 공개를 시작하지 않습니다.
• 공개 후 검사는 remote tag와 final Release identity, 정확히 일곱 개의 공개 asset, 내려받은
  archive의 checksums.txt SHA-256 일치를 확인합니다.
• local release 출력 정리는 저장소 루트에서 실제 dist·bin·tmp 디렉터리에만 한정하며,
  symlink와 일반 파일은 거부합니다. 오류 메시지에서도 명령 범위 credential 값은 가립니다.

호환성

• dva init이 생성하는 최소 설정 버전은 계속 0.1.44입니다.
• 공개는 여전히 CI가 아닌 승인된 수동 절차입니다. 이미 공개된 tag는 이동하거나 다시 만들지
  않습니다.

v0.1.46

DVA v0.1.46

v0.1.46은 DVA의 첫 공개 릴리스입니다. 하나의 dva.yml에서 개발 환경의 실행 대상을
선언하고, 이름 있는 plan으로 Compose·Kubernetes·로컬 프로세스 등을 일관되게 실행하는
현재 제품 모델을 담았습니다.

주요 기능

• Named plans: 재사용 가능한 stack 엔트리를 plan으로 조합하고 모든 lifecycle 동사에서
  같은 실행 이름을 사용합니다.
• 설정 진단과 마이그레이션: dva config validate, dva config migrate, dva doctor로
  설정 오류와 legacy 선언을 확인하고 안전하게 이전할 수 있습니다.
• 통합 실행 모델: Docker Compose, Kubernetes, Helm, 로컬/native 프로세스 등 여러 runner를
  동일한 plan 안에서 순서와 의존성에 따라 실행합니다.
• AI 런타임 스킬 설치: 내장된 dva와 dva-config 스킬을 Claude Code, Codex, OpenCode,
  Grok, Antigravity, Agent Mesh에 설치하고 상태를 확인하거나 제거할 수 있습니다.
• 충돌 방지와 명시적 takeover: 기존 파일을 기본적으로 보존하며, --takeover 시 검증 가능한
  백업을 만든 뒤 인수합니다. 백업 복원도 별도 명령으로 명시해야 합니다.
• 자동화 친화적 출력: dva manifest -f json과 전역 --json 출력으로 에이전트와 CI가
  프로젝트의 명령 및 상태를 구조적으로 읽을 수 있습니다.

호환성 참고

• 여러 실행 조합을 정의하는 새 설정에는 named plans를 권장합니다. plan이 없는 설정의
  whole-stack 호환 경로도 유지됩니다. dva config migrate는 legacy Compose 선언,
  applications:, stack.*.order를 현재 stack/plan 구조로 옮기고 자동 변환할 수 없는 항목은
  보고합니다. 제거된 dva stack, dva app, dva infra CLI 호출은 현재 lifecycle 명령으로
  직접 바꿔야 합니다.
• dva init이 생성하는 설정의 최소 스키마 버전은 0.1.44로 유지됩니다.
• 설치 및 체크섬 검증 절차는 공개 자산 검증 후 README와 USAGE에 추가됩니다.