backend-code-implementation-rules

name	backend-code-implementation-rules
description	백엔드 코드를 요구사항과 설계 결정에 맞게 수정하고 compile/test/typecheck 같은 구현 검증 evidence를 남겨야 할 때 사용하는 구현 규칙.

Backend Code Implementation Rules

목적

목표:

입력된 backend 요구사항과 backend_design_basis를 실제 코드 변경으로 옮기고 implementation_result를 남긴다.

성공 기준

• 변경 파일과 변경 이유가 명확하다.
• Source of Truth와 backend_design_basis가 구현에 반영된다.
• compile/test/typecheck 같은 구현 검증 evidence가 있다.
• frontend 또는 infra로 넘길 계약 불확실성이 분리된다.

핵심 규칙

• 요구사항과 명시적 제외사항 밖으로 범위를 넓히지 않는다.
• domain, application, storage, external, app 계층 책임을 섞지 않는다.
• transaction, consistency, exception, security 정책을 docs 기준으로 보존한다.
• compile/test/typecheck 실패가 있으면 구현 완료로 보고하지 않는다.

Architecture Review 재작업 입력

architecture_review_result 또는 remediation_input이 입력되면 Backend stage payload contracts의 필드를 기준으로 처리한다.

• violation payload의 근거와 수정 범위를 먼저 확인한다.
• requested_action 범위 안에서만 수정하고, 새 설계 결정을 임의로 만들지 않는다.
• 수정 후 rerun_required에 적힌 compile/test/typecheck를 다시 실행한다.
• 같은 위반이 해결되지 않거나 설계 결정 충돌이 의심되면 구현 완료로 보고하지 않고 불확실성으로 반환한다.

안티패턴

• backend_design_basis의 결정과 다른 구조로 구현한다.
• 테스트를 맞추기 위해 domain policy를 우회한다.
• frontend 표시 편의를 backend domain 책임으로 끌어온다.

금지사항

• architecture pass 여부를 직접 확정하지 않는다.
• architecture review나 security review를 구현 검증 evidence로 대체하지 않는다.
• 입력에 없는 파일을 불필요하게 수정하지 않는다.
• secret, token, credential을 코드나 로그에 남기지 않는다.

검증

• skill frontmatter가 현재 책임과 일치하는지 확인한다.
• 참조 docs 링크가 실제 파일을 가리키는지 확인한다.
• 이 skill에 orchestration, subagent lifecycle, scheduling 책임이 들어오지 않았는지 확인한다.

참조 Docs

• Backend docs
• Backend architecture
• Backend policies
• Backend stage payload contracts