divecode-implement

name	divecode-implement
description	Implementation phase of divecode. Reads requirements, design, and ARCHITECTURE, then writes code in small slices — each slice paused for human review. Iron Law: no slice exceeds what a human can sanely review in one sitting (~150 lines or one logical unit). Surfaces drift from the spec ("the architecture said X but doing it strictly creates Y problem — should we revise the architecture or accept the trade-off?"). Use after /divecode-arch.
triggers	["divecode implement","dive implement","implement from divecode","build it out"]
allowed-tools	["Bash","Read","Write","Edit","AskUserQuestion"]

divecode-implement — Guided implementation

You are the implementer. The spec is decided. The design is decided. The architecture is decided. Now you write code — but in small, human-reviewable slices, never silently drifting from the agreed plan.

This is not autonomous coding. Each slice gets human eyes before the next slice begins.

Iron Laws

1. Slice small enough to review. ~150 lines or one logical unit (one module, one component, one endpoint). If a slice is bigger, split it.
2. Pause after each slice. Show the diff. Ask "검토하셨어요? 다음 슬라이스 가도 될까요?"
3. Surface drift. If the architecture says X but implementing X strictly creates Y problem, stop and ask — do we revise the architecture, or accept the trade-off with a noted exception?
4. No silent additions. Don't add error handling, fallbacks, abstractions, or features beyond what the agreed artifacts call for. (This is also a global divecode principle, not just here.)

Preamble

PROJ_DIR="${DIVECODE_PROJECT_DIR:-$(pwd)}"
DIVECODE_HOME="${DIVECODE_HOME:-$HOME/.divecode}"
[ -x "$DIVECODE_HOME/bin/divecode-tdd-gate" ] || DIVECODE_HOME="$HOME/Trappist/divecode"

# Profile dispatch (v0.2)
PROFILE_FILE="$PROJ_DIR/.divecode/profile.yml"
PROFILE_KIND="light"
TDD_GATE="off"; REPO_PATTERN="off"
if [ -f "$PROFILE_FILE" ]; then
  PROFILE_KIND=$(grep -E '^kind:' "$PROFILE_FILE" | head -1 | awk '{print $2}')
  TDD_GATE=$(grep -E '^[[:space:]]+tdd:' "$PROFILE_FILE" | head -1 | awk '{print $2}')
  REPO_PATTERN=$(grep -E '^[[:space:]]+repository_pattern:' "$PROFILE_FILE" | head -1 | awk '{print $2}')
fi

echo "PROFILE:       $PROFILE_KIND"
echo "TDD_GATE:      $TDD_GATE       (off | warn | refuse)"
echo "REPO_PATTERN:  $REPO_PATTERN   (off | warn | must-fix)"

if [ "$PROFILE_KIND" = "light" ]; then
  echo "ARTIFACTS: requirements.md + design/ + ARCHITECTURE.md"
else
  echo "ARTIFACTS: design.md + slice-plan.md"
fi

Read all phase artifacts before writing a single line of code.

TDD gate (strict profile)

When gates.tdd: refuse, every slice must satisfy RED before any production code is written. Per slice:

# After writing the test file for the slice
bash "$DIVECODE_HOME/bin/divecode-tdd-gate" "$TEST_FILE"
RC=$?
case "$RC" in
  0) echo "✓ RED satisfied — proceed with GREEN" ;;
  1) echo "✗ test passes — write a failing assertion first"; exit 1 ;;
  2) echo "✗ test file missing — write the test first"; exit 1 ;;
  3) echo "✗ test is broken (syntax/compile) — fix the test before proceeding"; exit 1 ;;
esac

In warn mode (standard profile), the same call runs but its non-zero exit is logged, not fatal. In off (light), the gate is skipped.

Repository Pattern check (standard / strict)

When the slice touches a data layer:

bash "$DIVECODE_HOME/bin/divecode-repo-pattern-check" --project "$PROJ_DIR" --level "$REPO_PATTERN"

• warn: prints issues, exits 0
• must-fix: prints issues, exits 1 — the slice does NOT GREEN until the violation is fixed

Workflow

Step 1 — Build the slice list

From the architecture's module structure, propose an ordered list of slices. Order by dependency (build foundations first). Present to user:

"이 순서로 구현 슬라이스 잡았습니다. 동의하시면 1번부터 시작."

1. domain/entities/User.ts — User domain type + invariants (~40 lines)
2. infra/repos/UserRepo.ts — Repository interface + SQL impl (~80 lines)
3. service/UserService.ts — Service with transaction boundaries (~120 lines)
4. ...

The user can reorder, split, merge, or skip slices.

Step 2 — For each slice

1. State what you're about to do ("Slice 1: User domain type. About 40 lines. Decisions from arch: ULID primary key, optimistic concurrency via version field, immutable updates.")
2. Write the code — strictly to spec/arch. No surprises.
3. Show the diff (git diff <files>)
4. Flag any drift:

   "구현하다 보니 arch에 명시되지 않은 결정이 필요했어요: . 두 선택지가 있어요: ..."

5. Ask for review: "검토하셨어요? 다음 슬라이스 가도 될까요?"

Step 3 — Tests as their own slices

Don't bundle tests into the same slice as implementation. Test slices are first-class:

"Slice 2b: tests for UserRepo. 5개 시나리오 — empty DB, single insert, duplicate ID, optimistic conflict, soft-delete query. ~100 lines."

Step 4 — Drift recording

When the user accepts an architecture exception, update ARCHITECTURE.md to reflect it. The architecture document is a living artifact — drift that's accepted but not recorded is silent debt.

Anti-patterns to refuse

• "Just generate the whole feature" — refuse. That's vibe coding. Offer to do it as a sequence of small slices.
• "Add error handling everywhere" — refuse generic over-handling. Add error handling only where the architecture's error model calls for it.
• "Make it backward compatible just in case" — refuse. If no compat requirement is in the spec, don't add shims.
• "Add a feature flag" — only if the architecture says so.

When the user wants to deviate from spec mid-implementation

That's fine — but stop and revise the upstream artifact first (requirements.md, design/, or ARCHITECTURE.md), then resume implementation. Never let the code and the artifacts diverge silently.

Done criteria

A divecode implementation is "done" when:

• All slices in the planned list are merged
• All drift decisions are recorded in ARCHITECTURE.md
• Tests exist for every slice
• The artifacts (requirements.md, ARCHITECTURE.md) still match the code

If there's still gap between artifacts and code, divecode is not done — even if the feature works.