// 이 파일이 하는 일: "Gitea 200% 활용" 코스 — 우리 회사 Git 서버(edu.awesomedevapp.com:3000)를
// 단순한 '코드 창고'가 아니라 협업 본부로 쓰는 법을 8개 섹션으로 안내하는 정적 학습 페이지.
// (서버 투어 → 저장소 화면 읽기 → 이슈 → Pull Request와 리뷰 → diff 읽기 → 프로필 → 위키·릴리스 → 첫 이슈 실습)
// 학습 포인트: API 호출이 없는 '내용 고정' 페이지다. 스타일은 global.css의
// 가이드 전용 클래스(step-card, code-block, tip 등)를 재사용한다 — 색을 여기서 하드코딩하지 않는다.
// 텍스트 다이어그램은 JSX 중괄호/백틱 충돌을 피하려고 파일 상단의 백틱 문자열 상수로 정의한다.

import { Link } from 'react-router-dom';

// ── 텍스트 다이어그램 · 표 상수들 ──

const CODE_GITEA_MAP = `우리 Git 서버 한눈에 보기 — edu.awesomedevapp.com:3000

[브라우저] ──HTTPS──> [Caddy] ──> [Gitea 컨테이너(Docker)] ──> [AWS EC2 서버]

Gitea 첫 화면(대시보드)의 구성:
┌─────────────────────────────────────────────┐
│ 상단바: 로고 · 검색창 · [+] 새로 만들기 · 프로필 사진   │
├──────────────┬──────────────────────────────┤
│ 왼쪽          │ 가운데                         │
│ 내 저장소 목록  │ 활동 피드 — 동료들이 방금          │
│ (Repository)  │ 푸시·이슈·PR 한 기록이 실시간으로    │
│              │ 흘러가는 '회사 타임라인'            │
└──────────────┴──────────────────────────────┘

포트 3000 = "edu.awesomedevapp.com이라는 건물의 3000호에
Gitea가 산다"는 뜻이에요. (네트워크 코스의 IP·포트 그대로!)`;

const CODE_REPO_SCREEN = `저장소 화면의 3대 정보 — 이것만 읽어도 프로젝트가 보인다

① 파일 탐색기 (가운데 큰 영역)
   폴더/파일 목록 + 각 줄 오른쪽에 "마지막 커밋 메시지 · 시간"
   → 이 파일을 누가 왜 마지막으로 건드렸는지 한 줄 요약

② 커밋 히스토리 (Commits 숫자 클릭)
   프로젝트의 일기장. 최신이 맨 위.
   fcc4337  feat: 회원가입 화면 추가       김멘토  2시간 전
   72ddc36  fix: 로그인 버튼 겹침 수정      나      어제
   → 커밋 하나 = 일기 한 편. 클릭하면 그날 바뀐 내용 전부(diff)

③ 브랜치 선택 (파일 목록 위 드롭다운, 보통 main)
   브랜치 = 평행우주. main은 '정본 우주',
   feature/signup은 '회원가입 실험 중인 우주'.
   드롭다운을 바꾸면 그 우주의 파일들이 보여요.`;

const CODE_ISSUE_ANATOMY = `이슈(Issue) 하나의 구조 — 할 일 티켓의 해부도

#42  로그인 버튼이 모바일에서 잘려 보임          [열림 Open]
─────────────────────────────────────────────
본문: 어떤 문제인지 / 재현 방법 / 스크린샷
아래로 댓글이 대화처럼 이어짐 (카톡 스레드 느낌)

오른쪽 사이드바:
  담당자(Assignee)  ← 이 일을 '누가' 하는가
  라벨(Label)       ← bug / 기능요청 / 질문 ... 색깔 태그
  마일스톤          ← 어떤 목표(버전)에 속하는가

상태는 딱 두 가지: Open(진행 중) ↔ Closed(끝!)
커밋 메시지에 "fix: 로그인 버튼 수정 (#42)"처럼 번호를 적으면
커밋과 이슈가 자동으로 연결됩니다.`;

const CODE_PR_FLOW = `Pull Request(PR) = "제 브랜치 작업, 정본(main)에 합쳐 주세요" 요청서

내 브랜치에서 작업 → 푸시 → PR 열기 → 리뷰 → 승인 → 병합(Merge)

feature/signup ──┐
                 │  ← PR: "회원가입 화면 추가했어요, 봐 주세요"
main ────────────┴──────> main (병합 후 하나로!)

PR 화면의 탭 3형제:
  Conversation  대화 — 설명, 댓글, 리뷰 의견이 모이는 곳
  Commits       이 PR에 포함된 커밋 목록
  Files Changed 바뀐 파일 전부의 diff — 리뷰어가 사는 곳

리뷰어가 할 수 있는 것:
  · 특정 줄에 코멘트 달기 (줄 번호에 마우스 → [+] 클릭)
  · Approve(승인) / Request changes(수정 요청)
숙제를 내기 전에 짝꿍이 한 번 검사해 주는 것 — 그게 코드 리뷰예요.`;

const CODE_DIFF_READ = `diff 읽는 법 — 초록은 '새로 온 줄', 빨강은 '떠난 줄'

  @@ -12,4 +12,5 @@            ← "12번째 줄 근처가 바뀌었다"는 좌표
   function LoginButton() {     ← 회색: 안 바뀐 줄 (문맥용)
-    return <button>로그인</button>;          ← 빨강(-): 지워진 줄
+    return (
+      <button className="btn-primary">로그인</button>
+    );                                       ← 초록(+): 새로 생긴 줄
   }

읽는 요령:
1) 빨강·초록을 위아래로 짝지어 보세요 — "뭐가 뭐로 바뀌었나"
2) 한 줄만 바뀌어도 빨강 1줄 + 초록 1줄로 표시돼요 (수정 = 삭제+추가)
3) 파일 단위 요약: "3 files changed, +42 −7"
   → 파일 3개에서 42줄 생기고 7줄 사라짐. 리뷰 분량 가늠자!`;

const CODE_PROFILE = `프로필 페이지 = 나의 개발자 명함

edu.awesomedevapp.com:3000/내아이디  로 접속하면:

  [아바타]  이름 · 소속
  ────────────────────────
  잔디밭(Heatmap): 날짜별 활동량이 초록 칸으로 채워짐
  → 커밋·이슈·PR을 만들 때마다 칸이 진해져요.
    수습 기간이 끝날 때쯤 이 잔디밭이 여러분의 성장 그래프!

꾸미는 곳: 오른쪽 위 프로필 사진 → Settings(설정)
  · Avatar     사진 업로드 (얼굴이든 캐릭터든 OK)
  · Full Name  한글 이름 — 동료가 나를 찾기 쉽게!
  · Biography  한 줄 소개 (예: "26기 수습 · 프론트엔드 배우는 중")`;

const CODE_WIKI_RELEASE = `위키(Wiki)와 릴리스(Release) — 저장소의 '설명서'와 '출시 앨범'

위키 = 저장소에 딸린 공동 노트
  · 저장소 상단 탭 [Wiki] 클릭 → 페이지를 자유롭게 추가
  · 코드가 아닌 지식을 담아요: 개발 환경 세팅법, 회의 결정 사항,
    자주 겪는 에러 해결법(트러블슈팅 모음) 등
  · 마크다운으로 작성 — 학습 플랫폼 글쓰기와 같은 문법!

릴리스 = "여기까지가 v1.0" 하고 도장 찍기
  · 상단 탭 [Releases] → 특정 커밋에 버전 태그(v1.0.0)를 붙이고
    변경 요약(체인지로그)을 적어 발표
  · 게임 패치노트와 같아요: "이번 버전에서 뭐가 바뀌었나"를
    코드를 안 읽는 사람도 알 수 있게 정리한 것.`;

const CODE_FIRST_ISSUE = `실습: 내 첫 이슈 만들기 — 5분 완성 레시피

1) edu.awesomedevapp.com:3000 로그인
2) 연습용 저장소(멘토가 알려준 onboarding 저장소)로 이동
3) 상단 탭 [Issues] → 초록색 [New Issue] 버튼
4) 작성:
   제목: [자기소개] 26기 수습 ○○○ 입니다
   본문:
     안녕하세요! 오늘 Gitea 코스를 마친 ○○○입니다.
     - 배운 것 중 신기했던 것: (한 가지)
     - 궁금한 것: (한 가지)
     확인 부탁드려요 @멘토아이디
5) [Create Issue] 클릭 → 끝!

포인트: 본문에 @아이디 를 치는 순간 자동완성 목록이 떠요.
멘션(@)된 사람에게는 알림이 갑니다 — 카톡에서 친구를
@태그하는 것과 똑같아요. 답글이 달리면 나에게도 알림이 옵니다.`;

// ── 이 페이지 안에서만 쓰는 작은 부품들 ──
// 학습 포인트: 같은 모양이 반복되면 컴포넌트로 뽑는다. props만 바꿔 재사용.
function Section({ n, title, sub, children }) {
  return (
    <section className="step-card" id={`sec-${n}`}>
      <div className="step-head">
        <span className="step-num">{n}</span>
        <div>
          <h3>{title}</h3>
          {sub && <span className="step-sub">{sub}</span>}
        </div>
      </div>
      <div className="step-body">{children}</div>
    </section>
  );
}

function Code({ children }) {
  return <pre className="code-block"><code>{children}</code></pre>;
}

const SECTIONS = [
  { n: 1, label: '우리 Git 서버 투어' },
  { n: 2, label: '저장소 화면 읽기' },
  { n: 3, label: '이슈로 할 일 관리' },
  { n: 4, label: 'PR과 리뷰 화면' },
  { n: 5, label: 'diff 읽는 법' },
  { n: 6, label: '프로필 꾸미기' },
  { n: 7, label: '위키와 릴리스' },
  { n: 8, label: '실습: 첫 이슈' },
];

export default function ToolGiteaPage() {
  return (
    <div>
      {/* 히어로: Gitea를 코드 창고가 아닌 협업 본부로 */}
      <div className="hero">
        <div className="eyebrow">Course · 부록 · 도구</div>
        <h1>Gitea 200% 활용</h1>
        <p>
          Gitea는 코드를 넣어 두는 창고가 아니라, 어썸데브 개발팀이 매일 모여 일하는
          <strong> 협업 본부</strong>예요. 이 코스에서는 화면을 하나하나 읽는 법부터
          이슈·Pull Request·리뷰까지, 우리 서버(<span className="icode">edu.awesomedevapp.com:3000</span>)에서
          직접 손을 움직이며 익힙니다.
        </p>
        <div className="chip-row">
          <span className="chip">예상 소요 50분</span>
          <span className="chip">직접 해보기 3개</span>
          <span className="chip">준비물: Gitea 계정</span>
        </div>
      </div>

      {/* 섹션 바로가기 */}
      <nav className="pill-nav">
        {SECTIONS.map((s) => (
          <a key={s.n} href={`#sec-${s.n}`}>
            <b>{s.n}</b>
            {s.label}
          </a>
        ))}
      </nav>

      <Section n={1} title="우리 Git 서버 투어" sub="edu.awesomedevapp.com:3000 — 회사 개발팀의 타임라인">
        <p>
          GitHub는 들어봤죠? <strong>Gitea</strong>는 GitHub와 같은 종류의 서비스를
          <strong> 우리 회사 서버에 직접 설치해서 쓰는 것</strong>이에요. 남의 건물(GitHub)에
          세 들어 사는 대신, 우리 건물(AWS EC2 위 Docker 컨테이너)에 우리만의 작업실을
          차린 거죠. 그래서 회사 코드가 바깥으로 나가지 않아요.
        </p>
        <Code>{CODE_GITEA_MAP}</Code>
        <p>
          로그인하면 보이는 <strong>대시보드</strong>는 회사 개발팀의 SNS 피드 같은 곳이에요.
          "김멘토님이 mirim-app에 푸시했습니다", "이슈 #12가 닫혔습니다" — 팀이 지금 뭘 하고
          있는지 이 피드만 봐도 감이 잡힙니다.
        </p>
        <div className="tip">
          <b>직접 확인해 보기</b> 지금 <span className="icode">edu.awesomedevapp.com:3000</span>에
          로그인해서 대시보드 활동 피드를 위에서 아래로 읽어 보세요. 가장 최근에 움직인 저장소는
          무엇이고, 누가 무슨 작업을 했나요? 모르는 단어(push, merge...)가 나오면 메모해 두세요 —
          이 코스가 끝나면 전부 읽을 수 있게 됩니다.
        </div>
      </Section>

      <Section n={2} title="저장소 화면 읽기" sub="커밋 히스토리 · 브랜치 · 파일 탐색 — 3대 정보">
        <p>
          저장소(Repository)를 클릭하면 나오는 화면은 정보가 빽빽해서 처음엔 어지러워요.
          하지만 읽어야 할 건 딱 세 군데입니다.
        </p>
        <Code>{CODE_REPO_SCREEN}</Code>
        <p>
          <strong>커밋 히스토리</strong>는 프로젝트의 일기장이라고 했죠. 새 프로젝트에
          투입됐을 때 가장 빨리 파악하는 방법이 바로 <strong>최근 커밋 메시지 20개를
          쭉 읽는 것</strong>이에요. "아, 요즘 이 팀은 로그인 기능을 고치고 있구나"가
          코드 한 줄 안 읽고도 보입니다.
        </p>
        <p>
          <strong>브랜치</strong>는 평행우주 비유를 기억하세요. <span className="icode">main</span>은
          언제나 동작해야 하는 정본 우주라서, 새 기능은 반드시 별도 우주(브랜치)에서 실험한 뒤
          검사(리뷰)를 통과해야 정본에 합류합니다 — 그 합류 절차가 섹션 4의 Pull Request예요.
        </p>
        <div className="tip">
          <b>직접 확인해 보기</b> 우리 학습 플랫폼 저장소(<span className="icode">mirim-app</span>)에
          들어가 Commits를 클릭하고, 최근 커밋 10개의 메시지만 읽어 보세요.
          <span className="icode">feat:</span>, <span className="icode">fix:</span> 같은 접두어가
          보이나요? feat은 새 기능, fix는 버그 수정 — 메시지 첫 단어만으로 작업 종류를
          알 수 있게 한 팀의 약속입니다.
        </div>
      </Section>

      <Section n={3} title="이슈로 할 일 관리" sub="티켓이 곧 이슈 — 말로 하면 사라지고, 이슈로 쓰면 남는다">
        <p>
          "버튼이 이상해요"라고 말로 전하면 그 순간엔 전달되지만, 다음 날이면 잊혀요.
          그래서 개발팀은 모든 할 일을 <strong>이슈(Issue)</strong>라는 티켓으로 만듭니다.
          병원 접수증과 같아요 — 번호가 붙고(#42), 담당자가 정해지고, 처리가 끝나면
          닫힙니다(Closed). 접수증이 있으니 "그 일 어떻게 됐지?"가 사라지죠.
        </p>
        <Code>{CODE_ISSUE_ANATOMY}</Code>
        <p>
          좋은 이슈의 조건은 <strong>남이 읽고 바로 움직일 수 있는가</strong>예요.
          "안 돼요"보다는 "모바일 크롬에서 로그인 버튼이 화면 밖으로 잘려요.
          스크린샷 첨부합니다" — 재현 방법과 증거가 있으면 고치는 사람의 시간이
          절반으로 줄어듭니다. 어썸데브에서는 여러분이 받을 과제와 발견한 버그가
          전부 이 이슈로 오갈 거예요.
        </p>
        <div className="warn">
          <b>이슈 제목 한 줄이 절반이다</b> — "질문 있어요"(X) 대신
          "회원가입 페이지에서 비밀번호 규칙이 어디 정의돼 있나요?"(O)처럼,
          제목만 읽어도 내용이 짐작되게 쓰세요. 목록에서 보이는 건 제목뿐이니까요.
        </div>
      </Section>

      <Section n={4} title="Pull Request와 리뷰 화면" sub="제 작업, 정본에 합쳐 주세요 — 검사받고 합치는 문화">
        <p>
          내 브랜치(평행우주)에서 작업을 마쳤다면, 이제 정본(<span className="icode">main</span>)에
          합쳐야죠. 그런데 아무나 마음대로 합치면 정본이 망가질 수 있으니, 팀은
          <strong> Pull Request(PR)</strong>라는 절차를 둡니다. "제 작업 봐 주시고,
          괜찮으면 합쳐 주세요"라는 공개 요청서예요.
        </p>
        <Code>{CODE_PR_FLOW}</Code>
        <p>
          만드는 법은 간단해요. 브랜치를 푸시하면 Gitea가 저장소 상단에
          <strong> "New Pull Request"</strong> 안내를 띄워 줍니다. 클릭 →
          <strong> 어느 브랜치를(base ← compare)</strong> 합칠지 확인 → 제목과 설명 작성 →
          생성. 설명에는 "뭘 했고, 왜 했고, 어떻게 확인하면 되는지"를 적으면 리뷰어가
          기뻐합니다.
        </p>
        <p>
          리뷰어 입장에선 <strong>Files Changed</strong> 탭이 주무대예요. 바뀐 줄 번호에
          마우스를 올리면 나타나는 <span className="icode">+</span> 버튼으로 <strong>그 줄에
          정확히 코멘트</strong>를 달 수 있어요. 교과서 여백에 포스트잇을 붙이는 것과 같죠.
          다 보고 나면 <strong>Approve</strong>(승인) 또는 <strong>Request changes</strong>(수정
          요청)를 선택합니다. 승인이 모이면 <strong>Merge</strong> 버튼으로 정본에 합쳐지고,
          PR은 보라색 "Merged" 상태가 돼요.
        </p>
        <svg className="diagram" viewBox="0 0 640 360" xmlns="http://www.w3.org/2000/svg" role="img" aria-label="PR 흐름도: 브랜치 생성, 커밋, 푸시, PR 생성, 멘토 리뷰, 머지의 여섯 단계">
          <rect x="24" y="40" width="168" height="64" rx="8" fill="var(--card)" stroke="var(--line)" strokeWidth="1.5" />
          <text x="108" y="66" textAnchor="middle" fontSize="14" fontWeight="600" fill="var(--ink)">1. 브랜치 생성</text>
          <text x="108" y="88" textAnchor="middle" fontSize="12" fill="var(--muted)">feature/signup 우주 열기</text>

          <rect x="236" y="40" width="168" height="64" rx="8" fill="var(--card)" stroke="var(--line)" strokeWidth="1.5" />
          <text x="320" y="66" textAnchor="middle" fontSize="14" fontWeight="600" fill="var(--ink)">2. 커밋</text>
          <text x="320" y="88" textAnchor="middle" fontSize="12" fill="var(--muted)">일기 한 편 = 변경 한 묶음</text>

          <rect x="448" y="40" width="168" height="64" rx="8" fill="var(--card)" stroke="var(--line)" strokeWidth="1.5" />
          <text x="532" y="66" textAnchor="middle" fontSize="14" fontWeight="600" fill="var(--ink)">3. 푸시</text>
          <text x="532" y="88" textAnchor="middle" fontSize="12" fill="var(--muted)">Gitea 서버로 올리기</text>

          <line x1="192" y1="72" x2="228" y2="72" stroke="var(--primary)" strokeWidth="2" strokeLinecap="round" />
          <polyline points="220,66 228,72 220,78" fill="none" stroke="var(--primary)" strokeWidth="2" strokeLinecap="round" />
          <line x1="404" y1="72" x2="440" y2="72" stroke="var(--primary)" strokeWidth="2" strokeLinecap="round" />
          <polyline points="432,66 440,72 432,78" fill="none" stroke="var(--primary)" strokeWidth="2" strokeLinecap="round" />

          <path d="M 532 104 L 532 140 L 108 140 L 108 176" fill="none" stroke="var(--primary)" strokeWidth="2" strokeLinecap="round" />
          <polyline points="102,168 108,176 114,168" fill="none" stroke="var(--primary)" strokeWidth="2" strokeLinecap="round" />
          <text x="320" y="132" textAnchor="middle" fontSize="12" fill="var(--muted)">푸시하면 "New Pull Request" 안내가 뜬다</text>

          <rect x="24" y="180" width="168" height="64" rx="8" fill="var(--card)" stroke="var(--teal)" strokeWidth="1.5" />
          <text x="108" y="206" textAnchor="middle" fontSize="14" fontWeight="600" fill="var(--ink)">4. PR 생성</text>
          <text x="108" y="228" textAnchor="middle" fontSize="12" fill="var(--muted)">base ← compare 확인</text>

          <rect x="236" y="180" width="168" height="64" rx="8" fill="var(--card)" stroke="var(--teal)" strokeWidth="1.5" />
          <text x="320" y="206" textAnchor="middle" fontSize="14" fontWeight="600" fill="var(--ink)">5. 멘토 리뷰</text>
          <text x="320" y="228" textAnchor="middle" fontSize="12" fill="var(--muted)">Files Changed에 줄 코멘트</text>

          <rect x="448" y="180" width="168" height="64" rx="8" fill="var(--card)" stroke="var(--teal)" strokeWidth="1.5" />
          <text x="532" y="206" textAnchor="middle" fontSize="14" fontWeight="600" fill="var(--ink)">6. 머지</text>
          <text x="532" y="228" textAnchor="middle" fontSize="12" fill="var(--muted)">main에 합류 · Merged</text>

          <line x1="192" y1="212" x2="228" y2="212" stroke="var(--teal)" strokeWidth="2" strokeLinecap="round" />
          <polyline points="220,206 228,212 220,218" fill="none" stroke="var(--teal)" strokeWidth="2" strokeLinecap="round" />
          <line x1="404" y1="212" x2="440" y2="212" stroke="var(--teal)" strokeWidth="2" strokeLinecap="round" />
          <polyline points="432,206 440,212 432,218" fill="none" stroke="var(--teal)" strokeWidth="2" strokeLinecap="round" />
          <text x="422" y="200" textAnchor="middle" fontSize="12" fill="var(--muted)">Approve</text>

          <path d="M 320 244 L 320 276 L 108 276 L 108 250" fill="none" stroke="var(--amber)" strokeWidth="2" strokeDasharray="5 4" strokeLinecap="round" />
          <polyline points="102,258 108,250 114,258" fill="none" stroke="var(--amber)" strokeWidth="2" strokeLinecap="round" />
          <text x="214" y="296" textAnchor="middle" fontSize="12" fill="var(--amber)">Request changes → 고쳐서 다시 커밋·푸시</text>

          <circle cx="532" cy="308" r="7" fill="none" stroke="var(--teal)" strokeWidth="2" />
          <text x="524" y="313" textAnchor="end" fontSize="12" fill="var(--muted)">병합되면 main이 새 정본</text>
          <line x1="532" y1="244" x2="532" y2="301" stroke="var(--teal)" strokeWidth="2" strokeLinecap="round" />
        </svg>
        <p className="muted" style={{ fontSize: 12.5, textAlign: 'center', marginTop: 2 }}>그림: PR 흐름 — 브랜치 생성부터 머지까지, 수정 요청이 오면 커밋 단계로 되돌아간다</p>
        <div className="tip">
          <b>리뷰는 사람 검사가 아니라 코드 검사</b> — 코멘트를 받으면 "내가 혼났다"가 아니라
          "코드가 더 좋아질 기회"로 읽으세요. 어썸데브의 시니어들도 매일 서로의 PR에
          코멘트를 주고받아요. 리뷰가 없는 코드가 오히려 무서운 코드입니다.
        </div>
      </Section>

      <Section n={5} title="커밋 diff 읽는 법" sub="빨강과 초록의 언어 — 바뀐 것만 골라 보여주는 화면">
        <p>
          커밋이나 PR을 클릭하면 나오는 알록달록한 화면이 <strong>diff</strong>(차이)예요.
          파일 전체가 아니라 <strong>바뀐 부분만</strong> 보여줍니다. 숙제 첨삭본과 같아요 —
          빨간 줄(지운 것)과 초록 줄(새로 쓴 것)만 보면 뭐가 달라졌는지 바로 보이죠.
        </p>
        <Code>{CODE_DIFF_READ}</Code>
        <p>
          diff를 읽을 줄 알면 개발 생활이 달라져요. 동료의 커밋에서 배우고,
          "어제까지 되던 게 왜 안 되지?" 할 때 <strong>마지막 커밋의 diff부터</strong>
          확인하는 습관이 생깁니다. 범인은 대부분 가장 최근에 바뀐 줄에 있거든요.
        </p>
        <div className="tip">
          <b>직접 확인해 보기</b> <span className="icode">mirim-app</span> 저장소에서 아무 커밋이나
          클릭해 diff를 열어 보세요. ① 빨강·초록 쌍을 찾아 "뭐가 뭐로 바뀌었는지" 소리 내어
          설명해 보고, ② 상단의 "N files changed, +x −y" 요약과 실제 내용이 맞는지
          세어 보세요. 설명이 되면 diff 읽기 합격!
        </div>
      </Section>

      <Section n={6} title="프로필 꾸미기" sub="아바타·이름·잔디밭 — 온라인 명함 정리하기">
        <p>
          Gitea에서 여러분은 아이디로만 존재해요. 그런데 리뷰 코멘트, 이슈 담당자, 커밋
          기록 — 모든 곳에 프로필이 따라다닙니다. 아바타가 기본 이미지에 이름도 비어 있으면
          동료가 "이 사람 누구지?" 하게 되죠. <strong>프로필은 온라인 명함</strong>입니다.
          첫 출근 날 자리 정리하듯, 처음에 5분만 투자해 정리해 두세요.
        </p>
        <Code>{CODE_PROFILE}</Code>
        <p>
          <strong>잔디밭(활동 히트맵)</strong>은 게임의 출석 보상판 같은 재미가 있어요.
          커밋·이슈·PR 활동이 있는 날마다 칸이 초록으로 채워지는데, 억지로 채우는 게
          목표가 아니라 <strong>꾸준함이 눈에 보인다</strong>는 게 핵심이에요. 수습이 끝날 때
          자신의 잔디밭을 스크린샷해 두면 훌륭한 성장 기록이 됩니다.
        </p>
      </Section>

      <Section n={7} title="위키와 릴리스 한 입" sub="코드 밖의 지식(위키)과 버전의 이정표(릴리스)">
        <p>
          저장소에는 코드 말고도 두 개의 부속 공간이 있어요. 자주 쓰진 않아도
          <strong> 존재를 알아야 찾아갈 수 있는</strong> 곳들입니다.
        </p>
        <Code>{CODE_WIKI_RELEASE}</Code>
        <p>
          위키는 "이거 어떻게 하더라?"가 두 번 반복될 때 쓰는 곳이에요. 같은 질문을
          두 번 받았다면, 답을 위키에 적어 두고 다음부터는 링크를 주면 됩니다.
          릴리스는 반대로 <strong>바깥을 향한 발표</strong> — "v1.2가 나왔고, 이런 게
          바뀌었습니다"를 코드 모르는 사람도 읽을 수 있게 남기는 기록이에요.
        </p>
        <div className="warn">
          <b>위키 ≠ 코드 저장소</b> — 위키에 적은 내용은 코드 리뷰(PR)를 거치지 않고
          바로 수정돼요. 편한 만큼 책임도 함께입니다. 확실하지 않은 내용은
          "(확인 필요)"라고 표시해 두는 습관을 들이세요.
        </div>
      </Section>

      <Section n={8} title="실습: 내 첫 이슈 만들고 멘토 멘션하기" sub="배운 것을 실제 티켓 한 장으로 — 오늘의 졸업 과제">
        <p>
          이제 배운 걸 전부 씁니다. 이슈를 하나 만들고(섹션 3), 본문에서 멘토를
          <strong> 멘션(@)</strong>해서 알림을 보내는 것까지 — 이 한 장의 티켓이
          여러분의 Gitea 첫 발자국이자, 잔디밭(섹션 6)의 첫 초록 칸이 됩니다.
        </p>
        <Code>{CODE_FIRST_ISSUE}</Code>
        <ol className="olist">
          <li>이슈를 만든 뒤, 목록에서 내 이슈가 <strong>Open</strong> 상태로 보이는지 확인해요.</li>
          <li>멘토의 답글 알림이 오면(상단바 종 모양), 답 댓글을 한 번 달아 보세요 — 이슈는 대화 스레드라는 걸 체험하게 됩니다.</li>
          <li>대화가 끝나면 멘토가 이슈를 <strong>Close</strong>할 거예요. 열리고 → 오가고 → 닫히는 이슈의 한살이를 완주한 겁니다!</li>
        </ol>
        <div className="tip">
          <b>직접 확인해 보기(심화)</b> 이슈를 만들 때 오른쪽 사이드바에서
          <strong> 라벨(Label)</strong>을 하나 붙여 보세요(예: <span className="icode">question</span>).
          그리고 이슈 목록 상단의 필터에서 그 라벨로 걸러 보면 — 라벨이 왜 '색깔 태그'라고
          불리는지, 이슈가 수백 개가 돼도 왜 안 무서운지 감이 옵니다.
        </div>
      </Section>

      <div className="step-card">
        <div className="step-body">
          <h3 style={{ marginBottom: 6 }}>🦊 여기까지 왔다면</h3>
          <p className="muted">
            이제 Gitea는 코드 창고가 아니라 <strong>일이 흐르는 본부</strong>로 보일 거예요 —
            할 일은 이슈로, 작업은 브랜치로, 합류는 PR과 리뷰로, 변화는 diff로 읽는 흐름을
            전부 손으로 해봤으니까요. 이 흐름의 밑바닥에서 도는 Git 자체가 궁금하다면{' '}
            <Link to="/learn/git-deep"><strong>Git 기초</strong></Link> 코스로, 방금 만든 이슈처럼
            실제 과제를 받아 PR까지 완주해 보고 싶다면{' '}
            <Link to="/assignments"><strong>과제 게시판</strong></Link>에서 첫 티켓을
            골라 보세요. 여러분의 다음 초록 칸을 기다릴게요.
          </p>
        </div>
      </div>
    </div>
  );
}
