feat: 업무 상세 부속·활동 피드·내 업무 집계 + 페이지네이션 (5~8단계)

- 5단계(업무 상세 부속): 체크리스트(상세 읽기전용/수정폼 추가·삭제)·댓글/답글·파일 첨부(서버 로컬 업로드 폴더)·승인 워크플로우(요청/승인/수정요청 노트)
- 6단계(활동 피드): 저장소/멤버/업무 행위를 이벤트로 자동 적재, 저장소 활동 피드·업무 활동 탭 실연동(프론트가 type+payload로 문구 조립)
- 7단계(내 업무): 담당/지시 저장소 횡단 집계, MyTasksPage 실연동, TaskAssigneePage(/view) 제거
- 8단계(진행): 목록 페이지네이션 통일 — 백엔드 전체(공통 유틸 + 5개 목록, 저장소 업무는 세그먼트/검색/카운트) + 프론트 더보기(저장소 목록·내 업무 완료, 멤버·저장소 업무 대기)
- UI 보강: 업무 목록 댓글/첨부 분리표기, 첨부 배지 색상·라벨 통일, 완료 업무 D-Day 배지, 활동 이벤트 점검·보강(업무 수정/삭제·답글·첨부 삭제)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs/api-contract.md

@@ -42,10 +42,14 @@
 status 매핑보다 우선해 그대로 표준 응답으로 내려보내고, 프론트는 `BIZ_001` 코드일 때 서버 `message` 를 그대로 노출한다.
 예: 로그인 실패 → `BusinessException('BIZ_001', '이메일 또는 비밀번호가 올바르지 않습니다.', 401)`.
 
-### 페이지네이션
+### 페이지네이션 — **8단계에서 통일(진행 중)**
 
-목록 API 는 오프셋 기반: 쿼리 `?page=1&size=20`, 응답 `{ items: [...], total, page, size }`.
-(1단계에서는 단순 배열 허용, 7단계에서 페이지네이션으로 통일)
+목록 API 는 오프셋 기반: 쿼리 `?page=1&size=20`(기본 size 20, 최대 100), 응답 `{ items: [...], total, page, size }`.
+프론트는 **더보기 버튼**으로 점진 로드(시안에 페이지 UI 없음).
+
+- **백엔드 적용 완료**: `GET /repos`, `/repos/:id/members`, `/tasks/assigned`, `/tasks/issued`, `/repos/:id/tasks`(세그먼트/검색 + `counts` 동봉). 공통 유틸 `common/pagination`.
+- **프론트 적용 완료**: 저장소 목록, 내 업무. **남음**: 멤버, 저장소 업무 목록(RepoDetailPage).
+- 응답이 단순 배열 → `{ items, total, page, size }` 로 바뀌었으므로 프론트 composable/store 가 함께 갱신돼야 한다.
 
 ---
 
@@ -206,8 +210,8 @@ todo ─시작→ prog ─승인요청→ review ─승인→ done
 - 생성 시 status 는 항상 `todo`. 저장소 `doneCount/totalCount` 는 업무 status 집계(`done` 수/전체)로 실시간 반영, 멤버 `taskCount` 는 사용자별 담당 업무 수로 집계.
 
 `CreateTaskDto`: `{ title, content?: string[], assigneeIds: uuid[](≥1), dueDate?: ISO, checklist?: {text}[] }`
-`UpdateTaskDto`: `{ title?, content?: string[], assigneeIds?: uuid[], dueDate?: ISO|null }` — 제공된 필드만 갱신(체크리스트 항목 편집은 5단계).
-`RepoTask`(목록 행): `{ id(seq), title, status, dueDate: ISO|null, checklist: [done,total], commentCount, assignees: User[] }`
+`UpdateTaskDto`: `{ title?, content?: string[], assigneeIds?: uuid[], dueDate?: ISO|null, checklist?: {id?, text}[] }` — 제공된 필드만 갱신. `checklist` 제공 시 **전체 동기화**(id 있으면 기존 유지·완료 보존, 없으면 신규, 빠진 기존 항목은 삭제).
+`RepoTask`(목록 행): `{ id(seq), title, status, dueDate: ISO|null, checklist: [done,total], commentCount, fileCount, assignees: User[] }` — 목록 행은 댓글 수(말풍선)·첨부 수(클립)를 **분리 표기**(각 0이면 숨김).
 `TaskDetail`: `{ id(seq), repoId, repoName, title, status, content[], checklist: {id,text,done}[], assignees[], issuer: User|null, dueDate: ISO|null, createdAt, comments[], activities[], files[] }`
 > **comments/activities/files 는 5·6단계 영역** — 4단계 응답에서는 빈 배열로 내려간다. `approval` 객체도 5단계(현재 미포함).
 
@@ -219,14 +223,15 @@ todo ─시작→ prog ─승인요청→ review ─승인→ done
 
 ---
 
-## 5. 업무 상세 부속 — **5단계**
+## 5. 업무 상세 부속 — **5단계 ✅ 구현 완료**
 
-### 체크리스트
-| 메서드 | 경로 | 요청 | 응답 |
-|---|---|---|---|
-| POST | `.../tasks/:taskId/checklist` | `{ text }` | `ChecklistItem` |
-| PATCH | `.../checklist/:itemId` | `{ text?, done? }` | `ChecklistItem` |
-| DELETE | `.../checklist/:itemId` | — | `null` |
+> 모든 엔드포인트 `JwtAuthGuard` + 저장소 멤버. `:taskId`=seq(정수), `:itemId`/`:fileId`/`:commentId`=uuid.
+> 파일 저장은 **서버 로컬 업로드 폴더**(`UPLOAD_DIR`, 기본 `cwd/uploads`) 채택. 승인 워크플로우는 4단계 상태머신(`POST .../status`)을 노트와 함께 확장한 형태.
+
+### 체크리스트 — **상세 화면 읽기 전용 / 정의는 생성·수정 폼에서**
+- **완료 토글은 사용자가 하지 않는다** — 상세 화면에서는 표시만 하고, 완료는 승인 워크플로우에서 일괄 처리된다("승인 완료(→done) 시 체크리스트 항목 done 일괄 true", 4단계 부수효과).
+- **항목 추가/삭제(정의)는 업무 생성·수정 폼에서** 한다: 생성=`CreateTaskDto.checklist`, 수정=`UpdateTaskDto.checklist`(id 기준 전체 동기화).
+- (5단계 초기 설계의 `POST/PATCH/DELETE .../checklist` 항목별 토글 API 는 제거됨 — 항목 편집은 업무 수정 PATCH 로 통합.)
 
 ### 댓글 / 답글
 | 메서드 | 경로 | 요청 | 응답 |
@@ -240,7 +245,7 @@ todo ─시작→ prog ─승인요청→ review ─승인→ done
 | POST | `.../tasks/:taskId/files` | `multipart/form-data` | `Attachment` |
 | DELETE | `.../files/:fileId` | — | `null` |
 
-> **결정 필요**: 파일 저장소(로컬 볼륨 vs S3/MinIO). `Attachment`: `{ id, name, size, kind('pdf'|'zip'|'doc'|'img'), url }`.
+> **결정됨**: 파일 저장소 = **서버 로컬 업로드 폴더**(S3/MinIO 후순위). `Attachment`: `{ id, name, size(바이트), kind('pdf'|'zip'|'doc'|'img'), url(다운로드 경로), uploader: User|null, createdAt }`. 업로드 필드명 `file`. 다운로드는 `GET .../files/:fileId/download`(인증 쿠키로 접근, 인라인 스트리밍). 크기 표기는 프론트 `formatBytes`.
 
 ### 승인 워크플로우
 | 메서드 | 경로 | 요청 | 응답 |
@@ -251,29 +256,34 @@ todo ─시작→ prog ─승인요청→ review ─승인→ done
 
 ---
 
-## 6. 활동 피드 — **6단계**
+## 6. 활동 피드 — **6단계 ✅ 구현 완료**
 
 활동은 **2~5단계 행위에서 이벤트로 자동 적재**(쓰기 API 없음, 읽기만).
 
 | 메서드 | 경로 | 응답 |
 |---|---|---|
-| GET | `/repos/:repoId/activity` | `RepoActivityDay[]`(날짜 그룹) |
-| (업무 활동) | `TaskDetail.activities` 에 포함 | `Activity[]` |
+| GET | `/repos/:repoId/activity` | `ApiActivity[]`(최신순, 최대 200) — 날짜 그룹핑은 프론트 |
+| (업무 활동) | `TaskDetail.activities` 에 포함 | `ApiActivity[]`(해당 업무 seq) |
 
-`RepoActivityItem`: `{ tone, icon, actor: User, payload, createdAt }`
-> 서버는 이벤트 타입 + 행위자 + 대상만 저장하고, **표시 HTML 문구는 프론트에서 조립**(현재 mock 은 html 통문자열 — 연동 시 구조화 권장). 매핑: RepoActivityPage, TaskDetail 활동 탭.
+`ApiActivity`(원시): `{ id, type, actor: User|null, taskSeq: number|null, payload: object, createdAt }`
+- `type`: 저장소 `repo.created`/`repo.renamed`/`repo.visibility_changed`, 멤버 `member.invited`/`member.role_changed`/`member.removed`, 업무 `task.created`/`task.status_changed`/`task.comment_added`(답글 포함)/`task.file_attached`/`task.assignees_changed`/`task.due_changed`/`task.edited`(제목·내용·체크리스트)/`task.file_removed`/`task.removed`.
+- `payload`(타입별): `taskTitle`, `statusFrom`/`statusTo`, `targetName`, `roleType`, `newName`, `visibility`, `fileName`, `assigneeNames`, `dueDate` 등.
+> 업무 수정(`update`)은 **실제로 바뀐 측면만** 골라 적재한다(담당자 변경=`assignees_changed`, 마감 변경=`due_changed`, 제목·내용·체크리스트 변경=`edited`). 답글은 댓글과 동일 `task.comment_added`. 저장소 삭제는 활동도 함께 사라져 미적재, 저장소 설명/브랜치 변경·체크리스트 개별 완료는 미적재(승인 완료로 일괄 표현).
+> **서버는 이벤트 타입 + 행위자 + 대상(payload)만 저장**하고, 표시 문구/아이콘/톤·날짜 그룹은 **프론트가 type+payload 로 조립**(구조화 채택). 사용자 입력은 `escapeHtml` 후 신뢰 태그만 삽입(v-html XSS 방지). 적재는 베스트 에포트(실패해도 본 기능 안 막음), 6단계 도입 이후 발생분만 기록(소급 없음). 매핑: RepoActivityPage(저장소 활동), TaskDetail 활동 탭(업무 활동).
 
 ---
 
-## 7. 내 업무 (`/api/tasks`) — **7단계**
+## 7. 내 업무 (`/api/tasks`) — **7단계 ✅ 구현 완료**
 
 | 메서드 | 경로 | 요청 | 응답 |
 |---|---|---|---|
-| GET | `/tasks/assigned` | — | `MyTaskGroup[]`(상태 그룹) — 내가 담당 |
-| GET | `/tasks/issued` | — | `MyTaskGroup[]` — 내가 지시 |
+| GET | `/tasks/assigned` | — | `MyTaskRow[]` — 내가 담당(저장소 횡단) |
+| GET | `/tasks/issued` | — | `MyTaskRow[]` — 내가 지시(저장소 횡단) |
 
-저장소 횡단 집계. `MyTaskGroup`/`MyTaskRow` 는 mock 인터페이스와 동일하되 라벨류 제외, 원시값(`dueDate`, `status`) 기반.
-> 매핑 페이지: MyTasksPage(담당/지시 탭, 상태 그룹). `countActive` 는 프론트 유지.
+- 백엔드는 **플랫 행 배열**(`MyTaskRowResponse[]`)을 마감 임박순(마감 없음 뒤로)으로 반환하고, **상태 그룹핑·순서·라벨은 프론트가 파생**(활동 피드와 동일 패턴).
+- `MyTaskRowResponse`: `{ id(seq), repoId(slug), repoName, title, status, dueDate, checklist:[done,total], assignees: User[], issuer: User|null }`.
+- 프론트 파생: 담당 뷰=지시자 표시·그룹순서 `[changes,prog,todo,review,done]`, 지시 뷰=담당자 미니아바타·승인대기 강조(`내 승인 필요`)·그룹순서 `[review,prog,changes,todo,done]`. `dueLabel`/`dday`/`ddayLevel`/`overdue` 는 `taskDueInfo` 로 파생.
+> 매핑 페이지: MyTasksPage(담당/지시 탭, 상태 그룹). 행 클릭은 항상 `…/tasks/:taskId`(TaskDetailPage, 역할 기반 분기). **`TaskAssigneePage`(`/view`) 라우트·파일 제거 완료.**
 
 ---
 

docs/integration-progress.md

@@ -2,8 +2,8 @@
 
 > 프론트 UI(목업)를 NestJS 백엔드에 단계적으로 연동하는 작업의 진행 기록.
 > 계약/스키마 상세는 [`api-contract.md`](./api-contract.md) 참조.
-> 최종 갱신: 2026-06-17 · 현재 위치: **0~4단계 완료(+ Gitea 양방향 연동·템플릿 복제·생성폼 보강·멤버 프론트 연동·멤버 초대 자동완성·import 멤버 데드락 해소·cloneUrl/htmlUrl·giteaMissing 배지·업무 CRUD/상태머신/진행률 집계), 5단계(업무 상세 부속) 대기**
-> 남은 프론트 연동: 업무 상세의 댓글/체크리스트 토글/첨부/승인 노트(5단계). 그 외 6~8단계 미착수.
+> 최종 갱신: 2026-06-18 · 현재 위치: **0~7단계 완료(모든 화면 실데이터 연동). 8단계(마무리·선택) 진행 중 — 페이지네이션 통일 작업 중.**
+> 8단계 진행: **페이지네이션** 백엔드 전체 완료 + 프론트 2/4 도메인(저장소 목록·내 업무) 완료, 멤버·저장소 업무 도메인 대기. 그 외 8단계 항목(소셜 로그인·이메일 인증·알림·AI 패널·Redis 캐싱)은 미착수.
 
 ---
 
@@ -18,7 +18,7 @@
 
 ```
 0. 계약 정렬 ✅ → 1. 인증 ✅ → 2. 저장소 ✅ (+ Gitea 연동 ✅) → 3. 멤버 ✅(백엔드+프론트)
-→ 4. 업무 ✅(백엔드+프론트) → 5. 업무 상세 부속 → 6. 활동 피드 → 7. 내 업무 → 8. 마무리
+→ 4. 업무 ✅(백엔드+프론트) → 5. 업무 상세 부속 ✅(백엔드+프론트) → 6. 활동 피드 ✅(백엔드+프론트) → 7. 내 업무 → 8. 마무리
 ```
 
 ---
@@ -130,7 +130,7 @@
 - `shared/utils/format.ts`: `taskStatusLabel`·`taskDueInfo`(dueDate+완료여부→ dateLabel/dday/listLabel/overdue)·`monthDayKo` 추가.
 - `types/task.ts`, `composables/useTask.ts`(list/get/create/update/remove/changeStatus), `stores/task.store.ts`(API→mock `RepoTask`/`TaskDetail` 뷰 매핑: 마감/dday/상태 라벨 파생, 지시자 null 폴백).
 - 페이지 연동: **RepoDetailPage**(업무 목록 실데이터+로딩/빈상태, 툴바 ‘새 업무’ 버튼), **TaskCreatePage**(제목/내용 textarea/체크리스트/마감일/담당자=멤버 선택 드롭다운 → POST → 생성 상세로 이동), **TaskDetailPage**(상세 fetch, 삭제=DELETE, 승인=review→done·수정요청=review→changes), **TaskAssigneePage**(상세 fetch, 실제 status 로 카드 분기: 시작 todo→prog·승인요청 prog→review·재요청 changes→review, 삭제).
-- **업무 수정 UI**: `TaskCreatePage` 를 생성/수정 겸용으로 확장. 라우트 `/repos/:repoId/tasks/:taskId/edit`(`task-edit`) 추가 → `taskId` 있으면 편집 모드(기존 값 미리 채움 + `useTask().get` 로 원시값 로드 + 제출 시 PATCH `taskStore.update`). 헤더/버튼 라벨 전환(업무 수정/저장). 상세·담당자 페이지의 ‘수정’ 버튼을 `…/edit` 로 연결(기존엔 빈 생성 폼으로 오연결). **체크리스트 항목 편집은 5단계** — 수정 폼에선 표시·읽기전용(제목/내용/담당자/마감만 저장).
+- **업무 수정 UI**: `TaskCreatePage` 를 생성/수정 겸용으로 확장. 라우트 `/repos/:repoId/tasks/:taskId/edit`(`task-edit`) 추가 → `taskId` 있으면 편집 모드(기존 값 미리 채움 + `useTask().get` 로 원시값 로드 + 제출 시 PATCH `taskStore.update`). 헤더/버튼 라벨 전환(업무 수정/저장). 상세·담당자 페이지의 ‘수정’ 버튼을 `…/edit` 로 연결(기존엔 빈 생성 폼으로 오연결). (※ 수정 폼의 체크리스트 항목 추가/삭제는 2026-06-18 에 지원 — `UpdateTaskDto.checklist` 동기화. 제목/내용/담당자/마감과 함께 저장.)
 - 댓글/AI 에이전트 패널/첨부 업로드는 **로컬 데모 유지(5단계 실연동)**. 담당자 페이지의 `?state=` 쿼리 의존 제거 → `task.status` 기반 분기.
 - **역할 기반 액션 통합(2026-06-17)**: 목록은 항상 `TaskDetailPage`(`…/tasks/:taskId`)로 진입하고, 이 페이지가 **현재 사용자 역할로 액션을 분기**한다. `isIssuer`(task.issuer===me) / `isAssignee`(me ∈ assignees) 계산 → 지시자는 승인 대기(review)에서 승인/수정요청, 담당자는 `업무 시작`(todo→prog)·`승인 요청`(prog→review)·`다시 승인 요청`(changes→review)·승인 대기 중(review) 표시. 담당자가 "업무 시작"에 도달할 경로가 없던 문제 해소(기존 시작 버튼은 `/view`(TaskAssigneePage)에만 있었고 거기로 가는 링크가 mock MyTasksPage뿐이었음). `TaskAssigneePage`/`/view` 는 mock MyTasks 전용으로 잔존(7단계 정리). **한계**: 지시자가 아닌 admin은 화면상 승인 버튼 미노출(편집/삭제는 가능, 백엔드는 admin 승인 허용).
 - **UI 정리(2026-06-17)**: 공용 `RepoHeader` 기본 ‘새 업무’ 버튼 제거(`#actions` 슬롯 제공 시에만 렌더) → 상세 헤더 중복 버튼 해소. 작성 폼 ‘임시저장’ 제거, 체크박스 토글 비활성(어느 화면도 사용자 체크 불가), 담당자 칩을 입력칸 아래로 분리, 지시자 직무 줄 제거. 저장소 목록의 진행률 라벨(‘시작 전/67% 완료’) 제거(업무 수·바는 유지).
@@ -151,34 +151,87 @@
 - `CreateRepoDto.useTemplate=true` 면 빈 저장소 대신 복제 생성. 프론트 생성폼 템플릿 드롭다운=실제 옵션(없음 / `TtiPo/project-base`).
 - 라이브 검증: 생성된 repo 의 파일 트리가 `project-base` 와 동일하게 복제됨 확인.
 
+### 5단계 — 업무 상세 부속 ✅ (백엔드 + 프론트)
+
+**백엔드** `backend/src/modules/task/`
+- 신규 엔티티: `Comment`(답글은 `parent` 자기참조로 1단계 깊이, `attachment` 선택 연결, author/parent `Relation<>`), `Attachment`(원본명·`storedName`·size·mime·kind, uploader SET NULL). `Task` 에 승인 워크플로우 필드 추가(`approvalNote`/`approvalRequestedBy`/`approvalRequestedAt`/`changesNote`).
+- **체크리스트**: **상세 화면 읽기 전용**(완료 토글은 사용자가 하지 않음 — 승인 완료 시 일괄 처리, 4단계 부수효과). **항목 추가/삭제(정의)는 업무 생성·수정 폼에서** 한다: 생성=`CreateTaskDto.checklist`, 수정=`UpdateTaskDto.checklist`(id 기준 전체 동기화 — 기존 유지·완료 보존, 신규 추가, 빠진 항목 삭제). — *2026-06-18: 5단계 초기의 항목별 토글 API 제거 → 수정 PATCH 로 통합*
+- **댓글/답글**: `POST .../comments`(`text`/`fileId?`), `POST .../comments/:commentId/replies` — 멤버. 답글은 최상위 댓글에만.
+- **파일 첨부**: `POST .../files`(multipart, `FileInterceptor` + `dest`), `DELETE .../files/:fileId`, `GET .../files/:fileId/download`(`@Res` 직접 스트리밍, `Content-Disposition` UTF-8) — 멤버. 비ASCII 파일명 latin1→UTF-8 복원, MIME/확장자로 `kind` 파생.
+- **승인 워크플로우**: `POST .../approval/request`(prog/changes→review, note 선택), `/approve`(review→done), `/changes`(review→changes, note 필수). 4단계 상태머신 전이 로직을 `transition()` 으로 추출해 `POST .../status` 와 공유(역할 검증 동일). 승인 정보는 review 상태일 때만 `approval{requester,requestedAt,note}` 로 노출, changes 상태는 `changesNote`.
+- `TaskDetailResponse` 에 `comments`/`files`/`approval`/`changesNote` 실데이터 채움. 목록 `commentCount` 실집계. `activities` 는 6단계라 빈 배열 유지.
+- **파일 저장 방식(결정됨)**: **서버 로컬 업로드 폴더**(`upload.config.ts` `UPLOAD_DIR`, 기본 `cwd/uploads`). `@types/multer` 의존 없이 `UploadedDiskFile` 인터페이스 자체 정의. 운영 Dockerfile 이 `/app/uploads` 를 `node` 소유로 생성(비-root 쓰기 가능). dev 는 `./backend:/app` 바인드라 `backend/uploads`(gitignore)로 영속, 운영 영속이 필요하면 해당 경로에 볼륨 마운트(추후). S3/MinIO 는 후순위.
+- 테스트 `task.service.spec.ts` 보강(승인 요청/수정요청 역할, 체크리스트 비멤버 차단). 백엔드 **21 tests pass**, build/lint 0 err.
+
+**프론트** `frontend/src/`
+- `shared/utils/format.ts`: `formatBytes`(바이트→"18.4 MB"). `types/task.ts`: `ApiAttachment`/`ApiComment`/`ApiCommentReply`/`ApiApproval` + 부속 페이로드. `composables/useTask.ts`: 체크리스트/댓글/답글/파일(FormData)/승인 메서드. `stores/task.store.ts`: 댓글·첨부·승인 뷰 매핑(작성자 시간·역할배지·바이트 변환), 부속 변경 후 상세 재조회로 일관 갱신.
+- mock 뷰 타입(`ChecklistItem`/`Attachment`/`Comment`/`Reply`/`TaskDetail`)에 옵셔널 `id`/`url`/`changesNote` 추가(연동용, 기존 화면 호환).
+- **TaskDetailPage**: 체크리스트는 읽기 전용(표시만), 댓글/답글 실연동(로컬 데모 제거), 첨부 카드 항상 표시+업로드/다운로드 링크/삭제, 승인 요청 메모(prog/changes 카드 textarea)·수정 요청 메모(모달 textarea) 전송, 지시자 승인 카드에 요청 메모 노출·담당자 수정요청 카드에 보완 메모 노출. type-check/lint/build 0 err.
+
+> **한계**: 댓글에 파일 첨부(`fileId`)는 백엔드만 지원(상세 화면 UI 미노출). 업무 삭제 시 디스크 파일은 베스트에포트 정리(DB 행은 FK CASCADE). AI 에이전트 패널은 여전히 로컬 데모(8단계).
+
+### 6단계 — 활동 피드 ✅ (백엔드 + 프론트)
+
+**백엔드** `backend/src/modules/activity/`
+- `Activity` 엔티티: `repo`(FK, CASCADE)·`taskSeq`(int nullable, 업무 활동 필터용 — Task FK 대신 seq 저장)·`actor`(User SET NULL)·`type`·`payload`(jsonb)·`createdAt`. 표시 문구/아이콘/톤은 저장하지 않고 **프론트가 type+payload 로 조립**(구조화 채택).
+- `ActivityService`: `record()`(베스트 에포트 적재 — 실패해도 본 흐름 안 막음), `listForRepo(slug)`(최신순 200건), `listForTask(repoId, seq)`. `ActivityController`: `GET /repos/:repoId/activity`(인증, 조직 모델상 누구나 열람).
+- **이벤트 자동 적재**(다른 서비스가 `ActivityService.record` 호출): RepoService(생성/이름변경/공개범위), MemberService(초대/역할변경/제거), TaskService(생성·상태전이[`transition` 단일 지점]·댓글/답글·파일 첨부/삭제·업무 삭제·**업무 수정[변경 측면별: 담당자/마감/일반]**). 상태전이는 `task.status_changed` 단일 타입 + `payload{statusFrom,statusTo}` 로 적재하고 프론트가 from→to 로 문구 파생(시작/승인요청/승인/수정요청). 업무 수정(`update`)은 이전 상태와 비교해 **실제 바뀐 측면만** 적재(`task.assignees_changed`/`task.due_changed`/`task.edited`). `ActivityModule` 을 RepoModule·TaskModule 이 import(Activity 는 taskSeq 만 보관해 Task 엔티티 미참조 → 순환 없음).
+- `TaskDetailResponse.activities` 를 `ActivityService.listForTask` 로 채움(기존 빈 배열 제거).
+
+**프론트** `frontend/src/`
+- `format.ts`: `dayGroupKo`(오늘/어제/이번 주/날짜), `escapeHtml`(XSS 방지). `types/activity.ts`(`ApiActivity`), `composables/useActivity.ts`, `stores/activity.store.ts`(type+payload→톤/아이콘/문구 조립 + 날짜 그룹핑). **사용자 입력(이름/제목/파일명/표시명)은 escapeHtml 후 신뢰 태그만 조립**해 v-html 렌더.
+- **RepoActivityPage**: mock(`REPO_ACTIVITY`/`findRepo`) 제거 → 실연동(저장소 헤더=repo.store, 활동=activity.store, tone 필터, 로딩/빈 상태).
+- **TaskDetailPage 활동 탭**: `task.store` 의 `toTaskActivityView` 로 API 활동을 시안 Activity 뷰(tone/icon/html/statusFrom·To/file)로 매핑 → 실데이터 표시.
+- 검증: 프론트 type-check/lint/build 0 err, 백엔드 build/lint 0 err·20 tests pass.
+
+> **한계**: 활동은 **6단계 도입 이후 발생분만** 기록(소급 적재 없음). 활동 문구 내 업무 링크는 표시(`.tgt`)만 하고 클릭 라우팅은 생략. 체크리스트 개별 완료는 별도 이벤트 없이 승인 완료(`status_changed`→done)로 일괄 표현. 저장소 설명/브랜치 변경은 미적재.
+> *(2026-06-18 점검·보강: 업무 수정[담당자/마감/일반]·답글·업무 삭제·첨부 삭제 이벤트 추가.)*
+
+---
+
+### 7단계 — 내 업무 집계 ✅ (백엔드 + 프론트)
+- 백엔드 `MyTaskController` `GET /tasks/assigned`·`/tasks/issued`(저장소 횡단, `TaskService.listAssigned/listIssued`, 마감 임박순). 플랫 행 배열 반환, 그룹핑·라벨은 프론트 파생.
+- 프론트 `format.ts` `taskDueInfo`에 `ddayLevel` 추가, `types/my-task.ts`/`composables/useMyTask.ts`/`stores/my-task.store.ts`(담당/지시 뷰별 그룹 순서·라벨·미니아바타·승인대기 강조). **MyTasksPage** mock 제거→실연동(로딩/빈상태).
+- **`TaskAssigneePage`(`/view`)·`task-assignee-view` 라우트·파일 제거 완료**(상세가 역할 기반 통합). 행 클릭은 항상 `…/tasks/:taskId`.
+- 라이브 검증: `/tasks/assigned`·`/tasks/issued` 200·정상.
+
 ---
 
 ## 3. 남은 단계
 
-### 5단계 — 업무 상세 부속
-- 체크리스트 **개별 항목 토글/추가/삭제 영속**(현재 항목은 읽기 전용, 단 *승인 완료 시 일괄 완료*는 4단계에서 구현), 댓글/답글, **파일 첨부**, 승인 노트(승인 요청/수정 요청 시 메시지).
-- 승인 워크플로우 전용 엔드포인트(`approval/request|approve|changes`)는 상태 머신(4단계 `POST .../status`)에 노트·첨부를 더하는 형태로 확장.
-- **결정 필요**: 파일 저장소(로컬 볼륨 vs S3/MinIO).
+### 8단계 — 마무리(선택) · **진행 중**
 
-### 6단계 — 활동 피드
-- 2~5단계 행위를 이벤트로 적재(쓰기 API 없음, 읽기만). `GET /repos/:repoId/activity`.
-- 프론트: **RepoActivityPage**, TaskDetail 활동 탭.
-- **결정 필요**: 활동 표현 — 현재 mock은 HTML 통문자열 → 구조화(타입+행위자+대상) 권장.
+#### 8-1. 페이지네이션 통일 — 백엔드 ✅ / 프론트 2/4 도메인
 
-### 7단계 — 내 업무 집계
-- `GET /tasks/assigned`·`/tasks/issued`(저장소 횡단 집계). 프론트: **MyTasksPage**(담당/지시 탭).
-- **정리 대상**: 현재 mock `MyTasksPage` 가 유일하게 `…/tasks/:taskId/view`(`TaskAssigneePage`)로 링크 중. 4단계에서 상세(`TaskDetailPage`)가 역할 기반으로 통합됐으므로, 이 단계에서 MyTasks 를 실데이터로 연동하며 `/view` 링크를 `…/tasks/:taskId` 로 바꾸고 `TaskAssigneePage`/`task-assignee-view` 라우트를 제거한다.
+**결정(2026-06-18)**: 전체 목록 통일 + 프론트는 **더보기 버튼** 방식(시안에 페이지 UI 없음).
 
-### 8단계 — 마무리(선택)
-- 소셜 로그인(Google/Kakao), 이메일 인증, 알림, AI 에이전트 패널, Redis 캐싱, 전체 페이지네이션 통일.
+**백엔드 ✅ (완료)**
+- 공통 유틸 `backend/src/common/pagination/pagination.ts`: `resolvePage(page,size)`(범위 보정 + skip/take), `paginated(items,total,pg)`, `PaginatedResult<T>{items,total,page,size}`. 기본 size 20, 최대 100.
+- 컨트롤러는 `@Query('page', DefaultValuePipe(1), ParseIntPipe)` / `size` 로 받아 서비스에 전달.
+- 적용: `GET /repos`(RepoService.findAll), `GET /repos/:id/members`(MemberService.list), `GET /tasks/assigned`·`/tasks/issued`(TaskService.listAssigned/listIssued). 응답이 배열→`{items,total,page,size}` 로 변경.
+- `GET /repos/:id/tasks`(TaskService.list)는 **세그먼트(all/prog/todo/done)·검색(q)·페이지네이션 + 세그먼트 카운트** 동봉(`RepoTaskListResult = PaginatedResult<RepoTaskResponse> & { counts }`). 세그먼트 prog=prog+review, changes는 전체에만 집계(기존 RepoDetailPage 동작 보존). 기존 `?status` 쿼리는 `?segment` 로 대체.
+- 검증: 백엔드 build/lint 0 err, 20 tests pass(member spec 의 list 응답 `{items,total}` 으로 갱신).
+
+**프론트 — 2/4 도메인 ✅**
+- 공통 타입 `types/pagination.ts`(`Paginated<T>`, `DEFAULT_PAGE_SIZE=20`), 전역 `.load-more` 버튼 스타일(relay.css).
+- ✅ **저장소 목록**: `useRepo.list(page,size)`→`Paginated`, `repo.store`(total/page/hasMore/loadingMore + `loadMore` append), RepoListPage 하단 더보기 + total 카운트. 검색/공개여부 필터는 클라 유지(저장소 소규모).
+- ✅ **내 업무**: `useMyTask.assigned/issued(page,size)`, `my-task.store`(원시 행 누적 + 그룹핑은 computed 로 파생 → 더보기 시 같은 그룹에 합류, 담당/지시 각각 total/page/hasMore + `loadMoreAssigned`/`loadMoreIssued`), MyTasksPage 뷰별 더보기.
+- 검증: 프론트 type-check/lint/build 0 err.
+
+**프론트 — 남은 2/4 도메인 ⏳**
+- ⏳ **멤버**(RepoMembersPage): 더보기 페이지네이션. 단 **TaskCreatePage 가 담당자 후보로 전체 멤버를 사용**하므로, 거기엔 전체 로드(모든 페이지 순회 `fetchAll`)를 별도 보장해야 함.
+- ⏳ **저장소 업무**(RepoDetailPage): 현재 세그먼트/검색이 **클라이언트 필터** → 백엔드(`segment`/`q`)로 이전 + 세그먼트 카운트(`counts`) 연동 + 더보기. `useTask.list`·`task.store.fetchList` 응답 형태 변경 반영. (가장 복잡)
+- ⚠️ **전환기 주의**: 백엔드 응답이 이미 `{items,...}` 로 바뀌어, 프론트 연동 전까지 **멤버·저장소 상세 화면은 일시적으로 동작이 어긋날 수 있음**(다음 작업에서 해소).
+
+#### 8-2. 그 외(미착수)
+- 소셜 로그인(Google/Kakao OAuth), 이메일 인증, 알림, AI 에이전트 패널 실연동, Redis 캐싱.
 
 ---
 
 ## 4. 전환기 한계 (현재 시점)
 
-- **RepoActivityPage** 는 아직 mock `findRepo` 사용(6단계에서 해소). (RepoMembersPage 는 3단계, RepoDetail 업무 목록은 4단계에서 프론트 연동 완료)
-- **업무 상세의 댓글·체크리스트 토글·첨부·승인 노트**는 5단계 영역 — 현재 댓글/에이전트는 로컬 데모, 첨부/승인노트 UI 는 자리만 표시. 진행률은 4단계 집계로 실데이터.
-- `src/mock/relay.mock.ts` 는 아직 타입 정의(`Repo`/`User`/`TaskStatus`/`RepoTask`/`TaskDetail` 등) + 미연동 화면(활동/내업무) 데이터 공급원으로 사용 중. 해당 도메인이 연동되면 데이터는 제거하고 타입만 `src/types/` 로 이전.
+- **모든 화면이 실데이터로 연동 완료.** 남은 미연동 요소는 **AI 에이전트 패널(로컬 데모, 8단계)** 뿐.
+- `src/mock/relay.mock.ts` 는 이제 **타입 정의 공급원으로만** 사용(여러 store/page 가 `Repo`/`User`/`TaskStatus`/`RepoTask`/`TaskDetail`/`Activity`/`MyTaskGroup` 등 뷰 타입을 import). 정적 데이터(`REPO_ACTIVITY`/`MY_TASKS_*`/`REPOS`/`USERS` 등)는 사용처가 없어졌다 — 추후 타입만 `src/types/` 로 이전하고 데이터는 제거 가능(현재는 유지).
 
 ---