Dev — 작업 구현

Dev — 작업 구현은(는) 무엇을 하나요?

하나의 작업 번들을 구현하여 QA로 인계합니다. 이 스킬은 프로세스를 정의하며, references/role-boundaries.md에 자체 역할 경계를 포함합니다. 저장소가 에이전트 규칙(AGENTS.md, 역할-규칙 디렉터리 등)을 정의한 경우, 해당 규칙이 있으면 읽고 따라야 합니다. 이 스킬은 추가적인 접근 권한을 부여하지 않습니다.

사용하는 경우

• tasks/<task-id>/ 아래의 작업이 완료된 01-contract.md를 가지고 있고, 당신이 Dev 역할인 경우.
• 수직 슬라이스를 구현하고, DoD 명령을 실행하고, 증거를 기록하고, 인계해야 하는 경우.
• QA가 REWORK_REQUIRED를 발행한 후 작업을 다시 수행하는 경우.

사용하지 않는 경우

• 계약이 누락되었거나, 불완전하거나, 이의가 제기된 경우 — Planner에게 반환하십시오.
• 작업을 계획, 분할 또는 검토하거나 다른 에이전트의 작업을 확인하도록 요청받은 경우.
• 요청된 변경이 계약의 touch_files 외부에 있는 경우 — 에스컬레이션하거나 작업을 분할하십시오.

입력

• tasks/<task-id>/01-contract.md — 권위 있는 YAML frontmatter, touch_files, dod, 섹션 4의 BDD 행동 시나리오(Given-When-Then 불변속성) 및 상속된 ADR.
• 계약에서 참조하는 사양 앵커.
• 타입 검사 및 린트를 위한 프로젝트 명령, 기존 테스트 스위트, 그리고 dod.test_file에 선언된 QA 소유의 승인 대상.
• tasks/<task-id>/02-dev-workspace.md — 사용자가 작성하는 빈 양식.

출력

• touch_files에 나열된 경로에 대해서만 코드 변경.
• BDD 불변속성 및 순환 복잡도 제한(표준 $V(G) \le 10$, 경고 $11-15$는 02에서 정당화 필요, 심각 $> 15$는 금지)을 준수하는 코드.
• 메타데이터, 실제 변경 사항, 자체 검증 및 구현 이탈 테이블(행 DEV-001, DEV-002, ... 또는 명시적 None 행)이 포함된 완료된 02-dev-workspace.md.
• 정확히 하나의 핸드오프 마커: - [x] WAITING_FOR_QA, 모든 DoD 항목이 통과된 경우에만 체크.
• 01-contract.md, 03-qa-verification.md, 04-process.md 또는 tests/acceptance/**에 대한 편집 금지.

워크플로우

1. 범위 및 BDD 계약 확인. 01-contract.md의 frontmatter 및 섹션 4의 BDD 시나리오를 읽습니다. task_id가 디렉터리 이름과 일치하는지, touch_files, dod, adherence_adrs 및 Given-When-Then 불변속성이 정의되었는지 확인합니다. 누락되거나 모순된 항목을 Planner에게 보고합니다.
2. 작업 준비. 기본 커밋을 기록하고 프로젝트의 브랜치/커밋 규칙을 따릅니다. 검토자가 다시 열지 않는 한 이미 승인된 작업을 다시 열지 마십시오.
3. BDD 및 복잡성 제한 하에 수직 슬라이스 구현. touch_files에 있는 파일만 변경합니다. 섹션 4 및 dod.edge_cases에 선언된 Given-When-Then 불변속성을 충족하는 로직을 구현합니다. 단일 함수 순환 복잡도를 제어합니다(표준 $V(G) \le 10$). 복잡도가 경고 한계($11-15$)에 근접하면 리팩토링 패턴(메서드 추출, 전략/룩업 테이블, 가드 절)을 적용합니다. $V(G) > 15$인 경우, 진행 전에 리팩터링하십시오. tests/acceptance/**를 편집하거나 생성하지 마십시오.
4. 기계 검증 가능한 DoD 및 자체 검증 실행. dod.type_check와 dod.lint를 실행한 다음, 프로젝트의 기존 테스트를 실행합니다. 모든 dod.edge_cases 항목을 고려합니다. 모든 수정된 함수의 순환 복잡도를 자체 감사합니다. 승인 대상(dod.test_file)은 QA 소유입니다. 이미 존재하는 경우에만 실행하고, 직접 작성하거나 편집하지 마십시오. 아직 존재하지 않는 경우, 이를 02에 기록하고 QA가 검증 중에 실행하도록 합니다. 명령 및 결과를 캡처합니다.
5. 02-dev-workspace.md 작성. 브랜치, 기본/인계 커밋, 설계 노트, 실제로 변경된 각 파일에 대한 행, 순 라인 수를 기록하고 참인 각 자체 검증 항목에 체크합니다. 경고 수준 복잡도($11 \le V(G) \le 15$)를 가진 함수에 대해 명시적인 아키텍처적 정당성을 포함합니다. 통과하지 못한 항목은 체크하지 않은 상태로 둡니다. 구현 이탈 테이블을 완료합니다: 코드가 계약 또는 사양과 다른 각 위치에 대해 한 행(DEV-001, DEV-002, ...; 작업 add | modify | remove; #sec-* 앵커), 또는 이탈이 없으면 모든 셀에 None을 씁니다.
6. QA로 인계. 모든 자체 검증 항목이 통과하고 복잡성 제한이 충족된 경우에만 - [ ] WAITING_FOR_QA를 - [x] WAITING_FOR_QA로 변경합니다. 이 단일 체크박스가 인계 트리거입니다. 03 또는 04를 편집하지 마십시오.
7. 재작업 시. 03-qa-verification.md에서 QA의 실패 추적을 읽고, 계약 내에서만 수정하며, DoD를 재실행하고, 새로운 시도에 대해 02를 업데이트한 후 다시 인계합니다. 계약을 우회하는 대신 반복되는 실패를 에스컬레이션합니다.

품질 관문 (완료 선언 전)

• 변경된 모든 경로가 01-contract.md → touch_files에 나열되어 있습니다.
• 영향 범위 밖의 파일이 생성되거나 수정되지 않았습니다.
• 구현이 모든 Given-When-Then BDD 시나리오 및 행동 불변속성을 준수합니다.
• 타입 검사 및 린트가 성공적으로 종료됩니다. 프로젝트의 기존 테스트가 통과합니다.
• 순환 복잡도 자체 감사 통과: 모든 함수가 $V(G) \le 10$(또는 02에 정당성이 있는 $11-15$)을 충족합니다. $V(G) > 15$를 초과하는 함수는 없습니다.
• QA 소유의 승인 대상(dod.test_file)이 선언되었습니다. 아직 작성되지 않은 경우, 해당 사항이 QA를 위해 기록됩니다.
• 모든 dod.edge_cases 항목에 대한 구현/테스트 근거가 있습니다.
• 이 시도에 대해 02-dev-workspace.md가 완료되었습니다. 구현 이탈 테이블(이탈이 없으면 명시적 None 행)을 포함합니다.
• WAITING_FOR_QA만 체크되어 있습니다. 03 및 04는 수정되지 않았습니다.

실패 처리

• 계약 누락 또는 모순: 중단합니다. 해당 필드를 보고하고 Planner에게 수정을 요청합니다.
• 범위 외 변경 필요: 작업을 분할하거나 에스컬레이션합니다. touch_files 외부를 절대 편집하지 마십시오.
• DoD 명령 누락 또는 실행 불가: 명령과 오류를 보고합니다. 확인을 대충 넘기지 마십시오.
• DoD 실패: 구현을 수정하고 다시 실행합니다. 확인이 실패하는 동안 핸드오프 상자를 체크하지 마십시오.
• 복잡도 임계값 초과 ($V(G) > 15$): 핸드오프 전에 메서드 추출, 전략/룩업 테이블, 가드 절 또는 상태 패턴을 사용하여 리팩터링합니다. 절대 심각한 복잡도를 인계하지 마십시오.
• 도구 사용 불가: 프로젝트의 수동 명령을 사용하고 02에 증거를 기록합니다. 워크플로우는 선택적 도구에 의존해서는 안 됩니다.

04-process.md 및 도구

04-process.md는 파생 출력물입니다. 핸드오프 확인란이 체크된 후, 선택적 저장소 도구가 HANDOFF_QA_REQUESTED를 추가하고 macro_status/current_lock_holder를 업데이트합니다. 04를 직접 편집하지 마십시오. 도구가 없으면 git/CI와 체크된 상자에 의존하십시오.

QA_PASSED 이후: 사양 작성 소유권 이전

구현 이탈 테이블은 Dev가 해당 작업에 대해 마지막으로 전달하는 결과물입니다. QA가 QA_PASSED를 기록한 후, converge 스킬이 사양 작성 소유권을 가집니다: 확인된 이탈 사항을 .specs/02-tech-spec.md에 접고, 작업 번들을 보관하며, 변경 제안을 종료합니다.

• Dev는 절대 .specs/02-tech-spec.md를 편집하지 않으며 번들을 보관하지 않습니다.
• 구조적 이탈(새 컴포넌트, 변경된 경계, 새로운 ADR 수준 결정)은 조용히 수렴되는 대신 Planner/spec-generator로 에스컬레이션됩니다.
• QA가 재작업을 요청하면, 새로운 시도를 위해 이탈 테이블을 업데이트합니다. 사양 산문을 미리 작성하지 마십시오.

참조

• references/dev-protocol.md — 상세 체크리스트, 범위 확인, McCabe 순환 복잡도 제한, 리팩토링 패턴, 인계 및 재작업 절차.
• 역할 경계: references/role-boundaries.md — 쓰기 범위, 읽기 전용 범위, 불변속성 및 정직한 강제 모델(번들 제공, 외부 파일 불필요).
• 저장소 규칙: 채택 프로젝트가 정의하는 경우 AGENTS.md 및 역할-규칙 파일을 읽습니다. 이들은 요구 사항을 추가할 수 있지만 이 스킬이 작동하는 데 필요하지는 않습니다.
• 작업 번들 형식: task-decomposition 스킬(선택적 형제, 이 스킬은 해당 아티팩트만 소비합니다).

정직한 제한

이 스킬은 쓰기 접근을 부여하지 않으며 역할 격리를 강제할 수 없습니다. 저장소에 CI(예: git 기반 역할 감사) 또는 브랜치 보호가 있는 경우, 해당 계층이 권위 있는 계층입니다. 허용된 영향 범위를 정의하는 것은 이 문서가 아니라 계약입니다.