docs: add work rulebook and update session prep
This commit is contained in:
hyunho
@@ -3,10 +3,26 @@
|
||||
## Current Base
|
||||
|
||||
- branch: `total`
|
||||
- latest checked commit: `1d15cf9`
|
||||
- latest checked commit: `24852d4`
|
||||
- main history doc: [DEVELOPMENT_HISTORY.md](/home/hyunho/projects/mh-dashboard-organization/docs/DEVELOPMENT_HISTORY.md)
|
||||
- work rulebook: [WORK_RULEBOOK.md](/home/hyunho/projects/mh-dashboard-organization/docs/WORK_RULEBOOK.md)
|
||||
- dev/prod protocol: [DEV_PROD_DB_PROTOCOL.md](/home/hyunho/projects/mh-dashboard-organization/docs/DEV_PROD_DB_PROTOCOL.md)
|
||||
- regression checklist: [REGRESSION_CHECKLIST.md](/home/hyunho/projects/mh-dashboard-organization/docs/REGRESSION_CHECKLIST.md)
|
||||
- today prep note: [TODAY_WORK_PREP_2026-03-30.md](/home/hyunho/projects/mh-dashboard-organization/docs/TODAY_WORK_PREP_2026-03-30.md)
|
||||
|
||||
## Mandatory Start Rule
|
||||
|
||||
매일 아침 또는 그날의 첫 작업을 시작할 때는 코드를 수정하기 전에 반드시 아래 순서를 먼저 수행해야 한다.
|
||||
|
||||
1. Gitea 브랜치 상태 확인
|
||||
2. 열린 이슈 확인
|
||||
3. [WORK_RULEBOOK.md](/home/hyunho/projects/mh-dashboard-organization/docs/WORK_RULEBOOK.md) 확인
|
||||
4. 이 문서 확인
|
||||
5. 현재 워크트리의 미푸시 커밋, 변경 파일, 미추적 파일 확인
|
||||
|
||||
주의:
|
||||
|
||||
- 위 절차를 확인하기 전에는 새 코드 작성이나 기존 코드 수정부터 시작하지 않는다.
|
||||
|
||||
## What Was Finished
|
||||
|
||||
|
||||
143
docs/TODAY_WORK_PREP_2026-03-30.md
Normal file
143
docs/TODAY_WORK_PREP_2026-03-30.md
Normal file
@@ -0,0 +1,143 @@
|
||||
# Today Work Prep - 2026-03-30
|
||||
|
||||
## Current Local State
|
||||
|
||||
- working branch: `total`
|
||||
- HEAD: `24852d4` (`Fix seatmap slot matching and update member modal layout`)
|
||||
- remote tracking: `origin/total`
|
||||
- status: local branch is `ahead 2`
|
||||
- open PRs: none
|
||||
|
||||
untracked files:
|
||||
|
||||
- `docs/HISTORY_ASOF_DB_PLAN.md`
|
||||
- `incoming-files/6f.html`
|
||||
- `incoming-files/7f.html`
|
||||
- `incoming-files/center.html`
|
||||
|
||||
주의:
|
||||
|
||||
- `docs/NEXT_SESSION_CHECKPOINT.md` 의 최신 checked commit 은 아직 `1d15cf9` 로 남아 있다.
|
||||
- 실제 최신 작업 판단은 아래 최근 2개 로컬 커밋 기준으로 보는 것이 맞다.
|
||||
|
||||
## What Was Added After `origin/total`
|
||||
|
||||
### Commit `d666141`
|
||||
|
||||
- 3개 고정 오피스 자리배치도 반영
|
||||
- `technical-development-center`
|
||||
- `hanmac-building-6f`
|
||||
- `hanmac-building-7f`
|
||||
- 백엔드 `office_key` 기반 active viewer/layout 조회 지원
|
||||
- 프런트 자리배치도 탭에서 3개 오피스 선택 지원
|
||||
- `scripts/sync_prod_db_to_dev.sh` 추가
|
||||
- `docs/DEV_PROD_DB_PROTOCOL.md` 추가
|
||||
|
||||
### Commit `24852d4`
|
||||
|
||||
- slot 기반 자리 저장 시 slot matching 보정
|
||||
- 멤버 상세 모달 / 조직도 seat preview 레이아웃 조정
|
||||
- 회귀 점검용 `docs/REGRESSION_CHECKLIST.md` 추가
|
||||
- dev/prod sync script 후속 보정
|
||||
|
||||
## Remote Branch / Issue Snapshot
|
||||
|
||||
remote branches:
|
||||
|
||||
- `total` -> `1d15cf9`
|
||||
- `hyunho` -> `8efb5da`
|
||||
- `main` -> `7a0bd54`
|
||||
|
||||
open issues:
|
||||
|
||||
- `#11` `[P0] [버그] 자리배치도 회귀 오류`
|
||||
- `#12` `[P1] [DB] 공개용/작업용 seat_positions 스키마 불일치 정리`
|
||||
- `#13` `[P1] [인프라] 작업용 DB 동기화 절차 안정화 및 자동화`
|
||||
- `#14` `[P2] [리팩터링] 누적된 임시 로직 정리 및 중복 코드 제거`
|
||||
- `#10` `[P1] [분석] 1~2월 원본 정합성 보정 및 팀/개인별 검색 범위 개선 작업 정리`
|
||||
- `#9` `[P1] [이력관리] as-of date / 버전 누적 저장`
|
||||
- `#8` `[P2] [자리배치도] 좌석 클릭 시 개인 상위 조직 트리 표시`
|
||||
- `#7` `[P2] [자리배치도] 팀별 색상 오버레이 표시`
|
||||
- `#5` `[P2] [인증] 권한 제어 마무리 및 mock login 정리`
|
||||
- `#3` `[P1] [기능] 사무실 좌석 배치도 조회 및 관리자 편집 기능 고도화`
|
||||
- `#2` `[P0] [인프라] 백엔드 영속 저장 구조 운영 마무리`
|
||||
|
||||
현재 관계 해석:
|
||||
|
||||
- `#11` 은 최근 2개 커밋이 직접 겨냥한 회귀 묶음이다.
|
||||
- `#12`, `#13` 은 `#11` 재발 방지용 운영 과제에 가깝다.
|
||||
- `#3` 은 다중 오피스 도면 반영으로 많이 진척됐지만, 공개용 기준 회귀 검증 전에는 완료 처리하면 안 된다.
|
||||
- `#2` 는 단순 구현보다 dev/prod 데이터 운영 기준 정리가 핵심으로 바뀌었다.
|
||||
- `#5` 는 로그인 구현보다 권한 경계와 `/api/mock-login` 정리가 남은 상태다.
|
||||
|
||||
## Best Starting Point Today
|
||||
|
||||
오늘 첫 작업은 새 기능 추가보다, 최근 자리배치도/DB 동기화 작업을 검증 가능한 상태로 굳히는 쪽이 우선이다.
|
||||
|
||||
우선순위:
|
||||
|
||||
1. `#13` 프로토콜대로 작업용 DB를 `minimal` 범위로 동기화
|
||||
2. `docs/REGRESSION_CHECKLIST.md` 기준으로 자리배치도 회귀 확인
|
||||
3. 최근 2개 로컬 커밋을 `origin/total` 에 올릴지 결정
|
||||
4. 회귀가 남아 있으면 `#11` 계속, 없으면 `#5` 또는 `#12/#13` 후속 정리로 이동
|
||||
|
||||
이 순서가 맞는 이유:
|
||||
|
||||
- 현재 가장 최근 변경이 seatmap + DB sync 쪽에 몰려 있다.
|
||||
- 원격 `total` 은 아직 해당 수정들을 포함하지 않는다.
|
||||
- 검증 없이 다른 기능으로 넘어가면 회귀 원인과 신규 작업이 다시 섞인다.
|
||||
|
||||
## Concrete Start Checklist
|
||||
|
||||
세션 시작 즉시:
|
||||
|
||||
1. `docs/DEV_PROD_DB_PROTOCOL.md` 다시 확인
|
||||
2. 필요 시 `./scripts/sync_prod_db_to_dev.sh minimal`
|
||||
3. 로그인 상태 확인
|
||||
4. 아래 3개를 오피스별로 확인
|
||||
- 관리자 DnD 배치 저장
|
||||
- 조직도 상세 seat preview
|
||||
- 비관리자 seatmap 진입 / 표시
|
||||
|
||||
필수 확인 오피스:
|
||||
|
||||
- `기술개발센터`
|
||||
- `한맥빌딩 6층`
|
||||
- `한맥빌딩 7층`
|
||||
|
||||
## Recommended Decision Tree
|
||||
|
||||
### Case A. 회귀가 남아 있음
|
||||
|
||||
- 바로 `#11` 우선
|
||||
- 동시에 원인 범주를 분리
|
||||
- DB sync 실패
|
||||
- `seat_positions` 스키마 차이
|
||||
- 프런트 fallback 오류
|
||||
- 저장 API 로직 오류
|
||||
|
||||
### Case B. 회귀가 해소됨
|
||||
|
||||
- 최근 2개 커밋 푸시
|
||||
- Gitea `#11`, `#3`, `#2` 코멘트 상태 업데이트
|
||||
- 다음 메인 작업을 아래 중 하나로 선택
|
||||
- `#5` 권한 제어 / mock login 제거
|
||||
- `#12`, `#13` DB sync 안정화 마무리
|
||||
- `#9` history / as-of 구조 착수
|
||||
|
||||
## Suggested Main Task After Verification
|
||||
|
||||
가장 자연스러운 다음 메인 작업은 `#5` 보다 `#12`, `#13` 마무리다.
|
||||
|
||||
이유:
|
||||
|
||||
- 지금 이 코드베이스에서 자리배치도/조직도 검증은 DB 상태에 크게 좌우된다.
|
||||
- 권한 작업을 시작해도 검증 기반이 흔들리면 다시 혼선이 생긴다.
|
||||
- 반대로 sync 절차와 스키마 호환을 먼저 고정하면 이후 `#5`, `#9`, `#8`, `#7` 진행이 쉬워진다.
|
||||
|
||||
## Short Summary
|
||||
|
||||
- 코드 최신 상태는 로컬 `total@24852d4`
|
||||
- 원격 `total` 은 아직 최신 seatmap/sync 수정 전 상태
|
||||
- 오늘 첫 목표는 `#11` 관련 회귀 검증과 `#12/#13` 기반 정리
|
||||
- 검증 완료 전에는 새 기능보다 seatmap + DB 운영 안정화를 우선하는 것이 맞다
|
||||
211
docs/WORK_RULEBOOK.md
Normal file
211
docs/WORK_RULEBOOK.md
Normal file
@@ -0,0 +1,211 @@
|
||||
# Work Rulebook
|
||||
|
||||
## Purpose
|
||||
|
||||
이 문서는 이 프로젝트에서 매일 작업을 시작하고 마무리할 때 반드시 따를 운영 규칙을 고정하기 위한 룰북이다.
|
||||
|
||||
목표는 아래 4가지다.
|
||||
|
||||
- 완료된 기능의 회귀 방지
|
||||
- 코드 문제와 DB 문제의 혼선 방지
|
||||
- 작업 기록 누락 방지
|
||||
- 매일 같은 기준으로 안정적으로 이어서 작업
|
||||
|
||||
## Rule 0. Morning Start Mandatory Check
|
||||
|
||||
이 규칙은 강제 규칙이다.
|
||||
|
||||
매일 아침 또는 그날의 첫 작업을 시작할 때는, 코드를 수정하기 전에 반드시 아래 순서를 먼저 수행한다.
|
||||
|
||||
1. Gitea 브랜치 상태 확인
|
||||
2. 열린 이슈 확인
|
||||
3. 이 문서 `WORK_RULEBOOK.md` 확인
|
||||
4. 최신 체크포인트 문서 확인
|
||||
5. 현재 워크트리의 미푸시 커밋, 변경 파일, 미추적 파일 확인
|
||||
|
||||
위 5단계를 확인하기 전에는 새 코드 작성, 기존 코드 수정, 임의 테스트 진행을 시작하지 않는다.
|
||||
|
||||
즉:
|
||||
|
||||
- "오늘 첫 작업"의 시작점은 코드 수정이 아니라 상태 확인이다.
|
||||
- 이 절차를 건너뛰고 바로 수정 작업에 들어가는 것은 금지한다.
|
||||
|
||||
## Rule 1. Completed Feature Protection
|
||||
|
||||
완료 판정된 작업물의 기능과 코드는 함부로 건드리지 않는다.
|
||||
|
||||
세부 규칙:
|
||||
|
||||
- 직접 관련된 이슈가 없으면 완료 기능을 수정하지 않는다.
|
||||
- 완료 기능 수정이 필요하면 먼저 이유와 영향 범위를 이슈 또는 코멘트에 남긴다.
|
||||
- 단순 편의상 구조를 바꾸거나 정리하는 리팩터링으로 완료 기능 동작을 바꾸지 않는다.
|
||||
- 완료 기능을 수정한 경우에는 관련 회귀 검증까지 완료해야 한다.
|
||||
|
||||
핵심 원칙:
|
||||
|
||||
- "고치는 김에 같이 정리"를 금지한다.
|
||||
- 수정 범위는 현재 작업 목적에 필요한 최소 범위로 제한한다.
|
||||
|
||||
## Rule 2. Work Must Be Tied To An Issue
|
||||
|
||||
원칙적으로 이슈 없는 작업은 하지 않는다.
|
||||
|
||||
세부 규칙:
|
||||
|
||||
- 모든 작업은 기존 이슈에 연결하거나 새 이슈/작업 메모를 만든 뒤 시작한다.
|
||||
- 왜 하는 작업인지 한 줄로라도 남긴다.
|
||||
- 임시 대응도 예외가 아니다.
|
||||
|
||||
## Rule 3. Branch And Workspace Awareness
|
||||
|
||||
작업 전에 현재 브랜치와 워크트리 상태를 먼저 확인한다.
|
||||
|
||||
반드시 확인할 항목:
|
||||
|
||||
- 현재 브랜치
|
||||
- 원격 대비 ahead / behind 상태
|
||||
- 미푸시 커밋
|
||||
- 수정된 파일
|
||||
- 미추적 파일
|
||||
|
||||
금지:
|
||||
|
||||
- 로컬에서만 있는 상태를 기준 진실처럼 가정하기
|
||||
- 미정리 변경사항을 모른 채 새 작업을 덧붙이기
|
||||
|
||||
## Rule 4. DB Before Code Assumption
|
||||
|
||||
조직도, 멤버, 자리배치도, 권한 문제는 코드보다 DB 상태 영향을 먼저 의심한다.
|
||||
|
||||
세부 규칙:
|
||||
|
||||
- dev DB와 prod DB가 다른데 코드 버그로 단정하지 않는다.
|
||||
- 공개용 기준 데이터가 필요한 검증은 먼저 동기화 상태를 확인한다.
|
||||
- DB 차이를 무시한 검증 결과를 신뢰하지 않는다.
|
||||
|
||||
## Rule 5. Dev / Prod Protocol Is Mandatory
|
||||
|
||||
`docs/DEV_PROD_DB_PROTOCOL.md` 의 규칙은 권고가 아니라 작업 기준이다.
|
||||
|
||||
핵심 원칙:
|
||||
|
||||
- 코드 선행은 `8081`
|
||||
- 데이터 정본은 `8080`
|
||||
- `8081` DB는 독립 정본이 아니라 검증용 복제본처럼 다룬다
|
||||
|
||||
조직도/자리배치도/멤버 검증 전에는 필요 시 아래를 먼저 수행한다.
|
||||
|
||||
- `./scripts/sync_prod_db_to_dev.sh minimal`
|
||||
|
||||
분석 화면까지 공개용 기준으로 맞출 필요가 있으면 아래를 사용한다.
|
||||
|
||||
- `./scripts/sync_prod_db_to_dev.sh full`
|
||||
|
||||
## Rule 6. Validation Before Completion
|
||||
|
||||
완료 기준은 "코드를 썼다"가 아니라 "실제 동작을 검증했다"이다.
|
||||
|
||||
세부 규칙:
|
||||
|
||||
- 검증 없이 완료로 판단하지 않는다.
|
||||
- 감으로 확인하지 않고 체크리스트 기준으로 확인한다.
|
||||
- 회귀 가능성이 있는 수정은 관련 기능까지 같이 확인한다.
|
||||
|
||||
검증 기준 문서:
|
||||
|
||||
- `docs/REGRESSION_CHECKLIST.md`
|
||||
|
||||
## Rule 7. Seat Map Work Is High Risk
|
||||
|
||||
자리배치도 관련 작업은 항상 고위험 작업으로 취급한다.
|
||||
|
||||
작업 시 최소 확인 항목:
|
||||
|
||||
1. 관리자 DnD 배치 / 저장
|
||||
2. 조직도 상세의 seat preview
|
||||
3. 비관리자 seatmap 진입 / 표시
|
||||
|
||||
오피스가 여러 개면 아래 모두 확인한다.
|
||||
|
||||
- `기술개발센터`
|
||||
- `한맥빌딩 6층`
|
||||
- `한맥빌딩 7층`
|
||||
|
||||
기술개발센터만 보고 완료 처리하지 않는다.
|
||||
|
||||
## Rule 8. Auth / Schema / Sync Changes Are High Risk
|
||||
|
||||
아래 영역은 일반 기능 수정처럼 다루지 않는다.
|
||||
|
||||
- `auth.*`
|
||||
- `members`
|
||||
- `seat_maps`
|
||||
- `seat_slots`
|
||||
- `seat_positions`
|
||||
- 동기화 스크립트
|
||||
- 스키마 변경
|
||||
|
||||
이 작업은 반드시:
|
||||
|
||||
- 변경 이유 명시
|
||||
- 영향 범위 확인
|
||||
- 관련 검증 수행
|
||||
- 결과 기록
|
||||
|
||||
까지 포함해야 한다.
|
||||
|
||||
## Rule 9. Temporary Logic Must Be Tracked
|
||||
|
||||
mock, fallback, hotfix, 임시 우회 로직은 허용할 수 있다.
|
||||
하지만 반드시 추적 가능해야 한다.
|
||||
|
||||
세부 규칙:
|
||||
|
||||
- 왜 임시인지 기록한다.
|
||||
- 제거 또는 정식화할 이슈를 연결한다.
|
||||
- 운영 기준 로직처럼 장기 방치하지 않는다.
|
||||
|
||||
## Rule 10. End-Of-Day Closing Record
|
||||
|
||||
작업 종료 시 아래를 반드시 남긴다.
|
||||
|
||||
- 무엇을 했는지
|
||||
- 무엇을 검증했는지
|
||||
- 무엇이 아직 남았는지
|
||||
- 다음에 어디서 이어야 하는지
|
||||
|
||||
남길 위치:
|
||||
|
||||
- Gitea 이슈 코멘트
|
||||
- 또는 체크포인트 문서
|
||||
|
||||
둘 다 가능하면 둘 다 남긴다.
|
||||
|
||||
## Daily Start Checklist
|
||||
|
||||
매일 첫 작업 시작 전 체크:
|
||||
|
||||
- 현재 브랜치 확인
|
||||
- 원격 대비 커밋 상태 확인
|
||||
- 열린 이슈 확인
|
||||
- `WORK_RULEBOOK.md` 확인
|
||||
- 최신 체크포인트 확인
|
||||
- 미추적 / 수정 파일 확인
|
||||
- 오늘 작업이 코드 문제인지 DB 문제인지 먼저 구분
|
||||
- 공개용 기준 데이터 검증이 필요한지 판단
|
||||
|
||||
## Daily End Checklist
|
||||
|
||||
매일 작업 종료 전 체크:
|
||||
|
||||
- 오늘 변경 파일 정리
|
||||
- 검증 결과 정리
|
||||
- 미완료 항목 정리
|
||||
- 관련 이슈 코멘트 또는 문서 업데이트
|
||||
- 다음 시작 지점 명시
|
||||
|
||||
## One-Line Operating Principle
|
||||
|
||||
이 프로젝트의 작업 기준은 아래 한 줄로 요약한다.
|
||||
|
||||
- 상태를 먼저 확인하고, 완료 기능은 보호하며, DB와 검증을 무시하지 않고, 기록을 남기면서 작업한다.
|
||||
Reference in New Issue
Block a user