sync: agent-ops from agentic-framework v1.1.57
This commit is contained in:
parent
44f2dde2be
commit
6e82fb0304
11 changed files with 81 additions and 69 deletions
|
|
@ -1 +1 @@
|
|||
1.1.56
|
||||
1.1.57
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@
|
|||
|
||||
- roadmap은 장기 기억이고, agent-task는 실행 상태다.
|
||||
- current는 현재 작업 하나가 아니라 활성 Phase/Milestone 후보 창이다.
|
||||
- Phase와 Milestone은 큰 방향과 완료 기준을 담는다.
|
||||
- Phase와 Milestone은 큰 방향과 기능 단위를 담는다.
|
||||
- 구현 계획은 agent-task의 PLAN/CODE_REVIEW 루프에 둔다.
|
||||
- 완료 후보는 바로 archive하지 말고 `[검토중]`으로 둔다.
|
||||
- archive는 일반 작업에서 읽지 않는다. 과거 근거가 필요할 때만 링크를 따라 읽는다.
|
||||
|
|
@ -72,7 +72,7 @@
|
|||
- project rules는 프로젝트 특화 판단만 둔다.
|
||||
- domain rules는 특정 코드 영역 규칙만 둔다.
|
||||
- skills는 반복 작업 절차만 둔다.
|
||||
- roadmap은 장기 목표와 완료 기준만 둔다.
|
||||
- roadmap은 장기 목표와 기능 단위만 둔다.
|
||||
- agent-task는 실행 중인 작업 상태와 완료 산출물만 둔다.
|
||||
|
||||
## 경고 신호
|
||||
|
|
|
|||
|
|
@ -44,10 +44,10 @@
|
|||
- `[스케치]`는 방향성, 문제의식, 후보 범위, 미정 질문을 기록하는 컨셉 상태다. 구현 가능한 계획이 아니므로 `agent-task` 구현 계획 생성과 코드 구현을 시작하지 않는다.
|
||||
- `[스케치]` 항목은 `[계획]`으로 승격하기 위한 `승격 조건`, 사용자 결정, 범위 경계, 후속 Milestone 후보를 정리하는 것이 목적이다.
|
||||
- `[계획]` 이상 상태의 Milestone에서 `승격 조건` 섹션은 선택 사항이다. 섹션이 없거나 `- 없음`이면 템플릿 오류로 보지 않는다.
|
||||
- `[스케치]`를 `[계획]`으로 전환하려면 `승격 조건`의 미정 항목이 해소되고, 목표, 범위, 완료 기준, 직접적인 사용자 결정 항목, 후속 구현 단위가 구현 계획을 만들 수 있을 만큼 정리되어야 한다.
|
||||
- `[계획]`은 목표, 범위, 완료 기준, 구현 잠금, 결정 필요 항목이 정리되어 구현 계획을 만들 수 있는 상태다.
|
||||
- `[스케치]`를 `[계획]`으로 전환하려면 `승격 조건`의 미정 항목이 해소되고, 목표, 범위, 기능 Task, 직접적인 사용자 결정 항목, 후속 구현 단위가 구현 계획을 만들 수 있을 만큼 정리되어야 한다.
|
||||
- `[계획]`은 목표, 범위, 기능 Task, 구현 잠금, 결정 필요 항목이 정리되어 구현 계획을 만들 수 있는 상태다.
|
||||
- 갱신 범위에 포함된 기존 진행 상태 표기는 `[진행중]`으로 정리한다.
|
||||
- `[검토중]`은 모든 필수 작업과 완료 기준이 충족된 것으로 보이나, 사용자의 최종 완료 확인과 archive 승인이 아직 남은 완료 후보 상태다.
|
||||
- `[검토중]`은 모든 기능 Task와 Task 안에 명시된 검증이 충족된 것으로 보이나, 사용자의 최종 완료 확인과 archive 승인이 아직 남은 완료 후보 상태다.
|
||||
- `[검토중]` 항목은 활성 경로에 남기고 `current.md`의 활성 후보로 유지할 수 있다.
|
||||
- 검토 결과 보완이 필요하면 별도 reopen 상태를 만들지 않고 `[진행중]`으로 되돌린 뒤 `완료 리뷰` 또는 `작업 컨텍스트`에 보완 방향을 남긴다.
|
||||
- 검토 결과 보류 또는 폐기 결정이 나면 `[보류]` 또는 `[폐기]`로 전환한다.
|
||||
|
|
@ -61,12 +61,17 @@
|
|||
- Milestone 전체에서 사용자만 결정할 항목이 더 이상 없고 에이전트가 표준선에 따라 실행하면 되는 상태라면 `해제`로 둔다.
|
||||
- 선택한 Milestone에 `구현 잠금` 섹션이 없거나 상태가 `잠금`이면 코드 구현, `agent-task` 구현 계획, 세부 API/파일 구조 확정을 시작하기 전에 현재 요청에 직접 영향을 주는 `결정 필요` 항목만 사용자에게 확인한다.
|
||||
- 현재 요청과 직접 관련 없는 미정 항목은 잠금 상태로 남겨도 되며, 표준선으로 처리 가능한 작업을 막지 않는다.
|
||||
- 잠금 상태를 바꾸더라도 `필수 기능`이나 `완료 기준`을 자동 완료 처리하지 않는다.
|
||||
- 잠금 상태를 바꾸더라도 `기능` Task를 자동 완료 처리하지 않는다.
|
||||
- `[스케치]` 상태의 Milestone은 `구현 잠금`이 `해제`로 보이더라도 구현 계획과 코드 구현 대상이 아니다. 먼저 `[계획]`으로 승격해야 한다.
|
||||
|
||||
## Epic과 Task id
|
||||
|
||||
- Milestone 문서의 `필수 기능`은 Epic heading과 Task 체크리스트로 작성한다.
|
||||
- Milestone 문서의 실행 체크리스트는 `기능` 섹션 하나로 작성한다. 새 Milestone이나 갱신 범위에 포함된 Milestone에는 별도 `완료 기준` 섹션을 만들지 않는다.
|
||||
- 기존 Milestone에 `필수 기능`과 `완료 기준`이 분리되어 있으면, 갱신 시 `완료 기준`을 관련 기능 Task 안의 선택적 `검증:` 문구로 흡수하고 섹션을 제거한다.
|
||||
- 기능 Task는 기능 또는 산출물 단위다. 검증이 필요한 기능만 같은 Task 안에 `검증: <명령/확인 방법/기대 결과>`를 붙인다.
|
||||
- 검증이 명시된 Task의 `[x]`는 기능/산출물과 해당 검증이 모두 충족되었다는 뜻이다. 검증이 명시되지 않은 Task의 `[x]`는 기능/산출물 완료 근거가 충분하다는 뜻이다.
|
||||
- 사용자만 결정할 수 있는 검토/선택/우선순위 항목은 기능 Task로 쓰지 않는다. `구현 잠금`의 `결정 필요` 또는 `작업 컨텍스트`로 분리하고, 현재 구현에 직접 필요하면 plan 생성 전에 사용자 확인을 받는다.
|
||||
- `기능` 섹션의 Task 체크리스트는 Epic 바로 아래의 flat list를 기본으로 한다. 구현 세부, 테스트만 따로 떼어낸 하위 체크박스는 roadmap에 만들지 말고 plan 내부 체크리스트나 같은 Task의 `검증:`으로 흡수한다.
|
||||
- Epic heading은 `### Epic: [epic-id] <이름>` 형식을 사용한다.
|
||||
- Task는 `- [ ] [item-id] 설명` 또는 `- [x] [item-id] 설명` 형식을 사용한다.
|
||||
- epic-id와 item-id는 공백 없는 짧은 ASCII 토큰이며, 영문/숫자 segment 1~4개로 작성하고 segment 구분자는 `-`, `_`, `+`, `=`만 사용한다. 가능하면 1~3 segment를 우선하며, 전체 길이는 32자 이하를 권장한다.
|
||||
|
|
@ -90,7 +95,7 @@
|
|||
|
||||
## 완료 리뷰
|
||||
|
||||
- Task 완료나 Milestone 갱신 시 필수 Epic/Task와 완료 기준이 모두 evidence와 함께 `[x]`가 되었는지 확인한다.
|
||||
- Task 완료나 Milestone 갱신 시 모든 기능 Task와 Task 안에 명시된 검증이 evidence와 함께 `[x]`가 되었는지 확인한다.
|
||||
- 모두 충족된 것으로 보이면 Milestone을 `[완료]`로 바로 바꾸거나 archive로 이동하지 말고 `[검토중]`으로 바꾼다.
|
||||
- `[검토중]`으로 바꿀 때는 Milestone 문서에 `완료 리뷰` 섹션을 만들거나 갱신하고, 완료 근거 1~3줄과 사용자에게 필요한 최종 확인 항목을 남긴다.
|
||||
- 사용자가 완료를 승인한 뒤에만 `[완료]`로 전환하고 archive 이동을 수행한다.
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@
|
|||
<!-- [스케치] 예시:
|
||||
- [ ] 구현 가능한 목표와 범위를 확정한다.
|
||||
- [ ] 사용자만 결정할 제품/우선순위/책임 경계를 정리한다.
|
||||
- [ ] 완료 기준과 후속 구현 Milestone 후보를 나눈다.
|
||||
- [ ] 기능 단위와 후속 구현 Milestone 후보를 나눈다.
|
||||
-->
|
||||
|
||||
## 구현 잠금
|
||||
|
|
@ -39,7 +39,7 @@
|
|||
|
||||
- <이 Milestone에 포함되는 제품/기술/문서 범위>
|
||||
|
||||
## 필수 기능
|
||||
## 기능
|
||||
|
||||
<!--
|
||||
Epic은 `### Epic: [epic-id] <이름>` 형식을 사용한다.
|
||||
|
|
@ -47,6 +47,9 @@ epic-id는 공백 없는 짧은 ASCII 영문/숫자 segment 1~4개로 작성하
|
|||
Task는 `- [ ] [item-id] 설명` 형식을 사용한다.
|
||||
item-id는 공백 없는 짧은 ASCII 영문/숫자 segment 1~4개로 작성하고 segment 구분자는 -_+= 만 사용한다.
|
||||
epic-id와 item-id는 해당 Milestone 안에서만 유일하면 되고, 다른 Milestone에서는 같은 id를 다시 사용할 수 있다.
|
||||
Task는 기능 또는 산출물 단위다. 검증이 필요한 기능만 같은 Task 안에 `검증: <명령/확인 방법/기대 결과>`를 덧붙인다.
|
||||
Task 체크리스트는 Epic 바로 아래의 flat list로 유지하고, 구현 세부나 테스트만 따로 떼어낸 하위 체크박스는 만들지 않는다.
|
||||
별도 `완료 기준` 섹션은 만들지 않는다.
|
||||
-->
|
||||
|
||||
### Epic: [epic-id] <Epic 이름>
|
||||
|
|
@ -55,15 +58,15 @@ epic-id와 item-id는 해당 Milestone 안에서만 유일하면 되고, 다른
|
|||
|
||||
- [ ] [item-id] <구현 세부가 아니라 이 Milestone에서 달성해야 할 capability 또는 산출물>
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- [ ] <완료 여부를 확인할 수 있는 기준>
|
||||
<!-- 검증이 필요한 기능 Task 예시:
|
||||
- [ ] [item-id] <기능 설명>. 검증: <명령/확인 방법/기대 결과>
|
||||
-->
|
||||
|
||||
## 완료 리뷰
|
||||
|
||||
- 상태: <없음 | 요청됨 | 승인됨 | 보완 필요 | 보류 | 폐기>
|
||||
- 요청일: <YYYY-MM-DD | 없음>
|
||||
- 완료 근거: <모든 필수 Task와 완료 기준 충족 여부를 1~3줄로 요약>
|
||||
- 완료 근거: <모든 기능 Task와 Task 안에 명시된 검증 충족 여부를 1~3줄로 요약>
|
||||
- 리뷰 필요:
|
||||
- [ ] 사용자가 완료 결과를 확인했다
|
||||
- [ ] archive 이동을 승인했다
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@
|
|||
|
||||
- 브랜치: <branch-name 또는 확인 불가>
|
||||
- 변경 파일: <없음 | N개, 핵심 경로 요약>
|
||||
- 로드맵 근거: <Milestone 목표/범위/필수 기능/완료 기준과 연결된 근거>
|
||||
- 로드맵 근거: <Milestone 목표/범위/기능 Task와 연결된 근거>
|
||||
- 코드/테스트 근거: <코드, 테스트, diff, 문서에서 확인한 근거>
|
||||
|
||||
## 후보 우선순위
|
||||
|
|
|
|||
|
|
@ -27,10 +27,10 @@
|
|||
- 요청 내용, 현재 브랜치, 변경 파일, 관련 코드 경로를 보고 가장 관련 있는 활성 Phase와 Milestone 문서를 같은 세션에서 1회 읽는다.
|
||||
- 활성 Phase 또는 Milestone 밖의 작업이면 이 문서의 Phase 흐름을 확인하고 사용자에게 진행 또는 전환 여부를 확인한다.
|
||||
- 이 문서는 로드맵 생성/갱신, Phase 전환, Phase 추가/수정, 전체 구조 변경 요청이 있을 때만 읽는다.
|
||||
- 상세 작업과 완료 기준은 각 Milestone 문서의 `필수 기능`, `완료 기준`으로 관리한다.
|
||||
- 상세 작업은 각 Milestone 문서의 `기능`으로 관리한다. 검증이 필요한 기능만 같은 Task 안에 `검증:`으로 통합한다.
|
||||
- `[스케치]` Phase/Milestone은 방향성, 문제의식, 후보 범위, 미정 질문을 기록하는 컨셉 상태이며 구현 계획 생성 대상이 아니다.
|
||||
- `[스케치]` 항목은 `승격 조건`을 정리해 `[계획]`으로 전환한 뒤 구현 계획을 만든다.
|
||||
- 모든 필수 작업과 완료 기준이 충족된 Milestone은 먼저 `[검토중]`으로 두고, 사용자 완료 확인과 archive 승인을 받은 뒤 `[완료]`로 전환한다.
|
||||
- 모든 기능 Task와 Task 안에 명시된 검증이 충족된 Milestone은 먼저 `[검토중]`으로 두고, 사용자 완료 확인과 archive 승인을 받은 뒤 `[완료]`로 전환한다.
|
||||
- 완료된 Phase는 `agent-ops/roadmap/archive/phase/<phase-slug>/PHASE.md`로 이동하고, 하위 Milestone도 같은 archive Phase scaffold 아래에 둔다.
|
||||
- 진행중 Phase 안에서 완료된 Milestone은 활성 Phase 문서에 짧은 링크를 남기고, 상세 문서는 `agent-ops/roadmap/archive/phase/<phase-slug>/milestones/`로 이동한다.
|
||||
- archive `PHASE.md`는 Phase 자체가 완료 또는 폐기될 때만 만들며, 진행중 Phase의 완료 Milestone만 archive된 경우 archive Phase 디렉터리에 `milestones/`만 있을 수 있다.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
name: analyze-roadmap-position
|
||||
version: 1.9.1
|
||||
version: 1.10.0
|
||||
description: "지금 작업이 뭐지?, 현재 작업 분석, 남은 작업 확인 요청에 대해 로드맵이 있으면 활성 Phase/Milestone과 코드 상태를 함께 읽고, 로드맵이 없으면 git/active task 기준으로 현재 작업 지점과 남은 일을 추정하는 읽기 전용 스킬"
|
||||
---
|
||||
|
||||
|
|
@ -11,7 +11,7 @@ description: "지금 작업이 뭐지?, 현재 작업 분석, 남은 작업 확
|
|||
현재 브랜치, 변경 파일, 코드 구조를 분석하고, 로드맵이 있으면 활성 Phase와 활성 Milestone 문서를 함께 읽어 지금 작업이 어느 Phase/Milestone에 걸쳐 있는지와 남은 작업 후보를 보고한다.
|
||||
로드맵이 있으면 결과에는 추정한 Phase와 Milestone의 문서 링크를 함께 출력한다.
|
||||
Phase나 Milestone 후보가 여럿이면 가장 먼저 볼 후보와 다음 후보를 추천하고, 추천 근거를 짧게 남긴다.
|
||||
Milestone의 `필수 기능`에 Epic/Task id가 있으면 남은 작업과 판단 근거에 함께 표시해 사용자가 짧은 id로 후속 지시를 할 수 있게 한다.
|
||||
Milestone의 `기능`에 Epic/Task id가 있으면 남은 작업과 판단 근거에 함께 표시해 사용자가 짧은 id로 후속 지시를 할 수 있게 한다.
|
||||
`current.md`만 보고 현재 작업 위치를 단정하지 않고, 실제 코드 상태와 요청 내용을 근거로 판단한다.
|
||||
`agent-ops/roadmap/` 디렉터리 또는 `current.md`가 없으면 로드맵 분석을 건너뛰고 git 상태, active `agent-task`, 요청 문장을 기준으로만 보고한다.
|
||||
|
||||
|
|
@ -41,7 +41,7 @@ Milestone의 `필수 기능`에 Epic/Task id가 있으면 남은 작업과 판
|
|||
- `agent-ops/roadmap/current.md`를 읽고 활성 Phase, 활성 Milestone 후보와 선택 규칙을 파악한다.
|
||||
- `current.md`의 후보가 `agent-ops/roadmap/archive/**`를 가리키면 해당 문서는 읽지 말고 로드맵 갱신 필요 항목으로 기록한다.
|
||||
- 관련 활성 Phase 문서를 읽고 Phase 목표, Milestone 흐름, Phase 경계를 확인한다.
|
||||
- 관련 활성 Milestone 문서를 읽고 목표, 상태, 승격 조건, 범위, 필수 기능, 완료 기준, 완료 리뷰, 범위 제외, 구현 잠금을 확인한다. `승격 조건`은 `[스케치]`에서만 필수이며, `[계획]` 이상에서 섹션이 없으면 `없음`으로 본다.
|
||||
- 관련 활성 Milestone 문서를 읽고 목표, 상태, 승격 조건, 범위, 기능 Task, 완료 리뷰, 범위 제외, 구현 잠금을 확인한다. `승격 조건`은 `[스케치]`에서만 필수이며, `[계획]` 이상에서 섹션이 없으면 `없음`으로 본다.
|
||||
- 목록이 많으면 사용자 요청이나 변경 파일과 관련 높은 Phase/Milestone부터 읽는다.
|
||||
- `current.md` 형식이 맞지 않으면 `ROADMAP.md`를 자동으로 읽지 말고 로드맵 컨텍스트 불확실성을 보고한다.
|
||||
|
||||
|
|
@ -53,8 +53,8 @@ Milestone의 `필수 기능`에 Epic/Task id가 있으면 남은 작업과 판
|
|||
3. **Phase/Milestone 매칭**
|
||||
- 로드맵이 없거나 `current.md`가 없으면 Phase/Milestone을 추정하지 않는다. `추정 Phase`, `추정 Milestone`, 문서 링크는 `없음`으로 기록하고 아래 Phase/Milestone 비교 항목은 수행하지 않는다.
|
||||
- 활성 Phase의 목표/경계와 변경 파일/요청 내용을 비교한다.
|
||||
- 활성 Milestone의 목표, 범위, 완료 기준, 범위 제외 항목과 변경 파일/요청 내용을 비교한다.
|
||||
- Milestone의 `필수 기능`에서 관련 Epic/Task id가 있으면 판단 근거와 남은 작업에 함께 기록한다.
|
||||
- 활성 Milestone의 목표, 범위, 기능 Task, 범위 제외 항목과 변경 파일/요청 내용을 비교한다.
|
||||
- Milestone의 `기능`에서 관련 Epic/Task id가 있으면 판단 근거와 남은 작업에 함께 기록한다.
|
||||
- 여러 Milestone 후보에서 같은 epic-id 또는 item-id가 보이면 id만으로 위치를 확정하지 말고 Milestone 이름과 문서 링크를 함께 제시한다.
|
||||
- 활성 Milestone의 `구현 잠금` 섹션, 상태, `완료 리뷰` 섹션, `결정 필요` 항목을 함께 확인한다.
|
||||
- 하나의 Milestone에 명확히 속하면 단일 후보로 보고한다.
|
||||
|
|
|
|||
|
|
@ -128,6 +128,7 @@ Before writing the verdict:
|
|||
|
||||
- Compare actual source files against every planned checklist item.
|
||||
- Compare the plan `구현 체크리스트` and review stub `구현 체크리스트`; item text/order must match.
|
||||
- If a checklist item contains integrated verification for a feature, treat that feature item as incomplete until both implementation evidence and the matching verification output are present. Do not accept a separate unchecked completion-criteria item as a substitute.
|
||||
- Confirm the implementation marked the matching checklist items in the active review file, including the final mandatory `CODE_REVIEW-*-G??.md` completion item.
|
||||
- Treat blank placeholder sections, missing actual implementation notes, missing checklist completion, or missing actual stdout/stderr in the active review file as a completeness or verification-trust failure.
|
||||
- Grep renamed/removed symbols for stale references.
|
||||
|
|
@ -158,7 +159,7 @@ Severity semantics:
|
|||
|
||||
Issue severity:
|
||||
|
||||
- `Required`: correctness, API contract, missing required test, plan-completeness issue, or incomplete/placeholder `CODE_REVIEW-*-G??.md` content required from the implementing agent.
|
||||
- `Required`: correctness, API contract, missing required test, missing verification that was integrated into a feature item, plan-completeness issue, or incomplete/placeholder `CODE_REVIEW-*-G??.md` content required from the implementing agent.
|
||||
- `Suggested`: useful improvement that should enter the loop but does not block correctness.
|
||||
- `Nit`: tiny cleanup; may be recorded without forcing WARN.
|
||||
|
||||
|
|
@ -357,7 +358,7 @@ Report Required/Suggested counts, archive names, the final task archive path for
|
|||
| Dimension | Check |
|
||||
|-----------|-------|
|
||||
| Correctness | Logic, edge cases, concurrency, errors |
|
||||
| Completeness | All planned checklist items done, including matching plan/review `구현 체크리스트` completion |
|
||||
| Completeness | All planned checklist items done, including integrated implementation+verification feature items and matching plan/review `구현 체크리스트` completion |
|
||||
| Test coverage | Required tests present and meaningful |
|
||||
| API contract | Call sites, compatibility, docs |
|
||||
| Code quality | No debug prints, dead code, leftover TODOs |
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
name: create-roadmap
|
||||
version: 1.13.1
|
||||
version: 1.14.0
|
||||
description: AI-first 개인/소규모 프로젝트의 전체 목표, Phase scaffold, Phase 하위 Milestone 문서, current.md 활성 Phase/Milestone 창, archive Phase scaffold를 처음 생성하는 공통 스킬
|
||||
---
|
||||
|
||||
|
|
@ -11,7 +11,7 @@ description: AI-first 개인/소규모 프로젝트의 전체 목표, Phase scaf
|
|||
`agent-ops/roadmap/` 하위에 `Roadmap -> Phase -> Milestone` 기반 한국어 로드맵 구조를 처음 생성한다.
|
||||
전체 로드맵은 전체 방향과 Phase index만 담당하고, 일반 작업에서는 `current.md`의 활성 Phase/Milestone 링크와 관련 문서만 읽도록 만든다.
|
||||
Milestone은 구현 계획이 아니라 방향성, 범위, 위험, 확인 필요 사항을 기록하는 협업 문서다.
|
||||
Epic과 Task는 별도 파일로 분리하지 않고 Milestone 문서의 `필수 기능` 안에서 관리한다.
|
||||
Epic과 Task는 별도 파일로 분리하지 않고 Milestone 문서의 `기능` 안에서 관리한다. 별도 `완료 기준` 섹션은 만들지 않고, 검증이 필요한 기능에만 같은 Task 안의 `검증:` 문구로 통합한다.
|
||||
|
||||
## 언제 호출할지
|
||||
|
||||
|
|
@ -52,7 +52,7 @@ agent-ops/
|
|||
| `agent-ops/roadmap/ROADMAP.md` | 전체 목표와 Phase 흐름만 담는 최상위 지도. 로드맵 생성/갱신/Phase 전환 때만 읽는다 |
|
||||
| `agent-ops/roadmap/current.md` | 활성 Phase와 활성 Milestone 후보, 선택 규칙을 담는 얇은 포인터 |
|
||||
| `agent-ops/roadmap/phase/<phase-slug>/PHASE.md` | Phase 목표, 상태, Milestone 흐름, Phase 경계를 담는 문서 |
|
||||
| `agent-ops/roadmap/phase/<phase-slug>/milestones/<milestone-slug>.md` | 일반 작업 시 읽는 Milestone 단위 목표, 스케치 승격 조건, 구현 잠금, 범위, Epic/Task 체크리스트, 완료 기준, 범위 제외 항목 |
|
||||
| `agent-ops/roadmap/phase/<phase-slug>/milestones/<milestone-slug>.md` | 일반 작업 시 읽는 Milestone 단위 목표, 스케치 승격 조건, 구현 잠금, 범위, 기능 Epic/Task 체크리스트, 범위 제외 항목 |
|
||||
| `agent-ops/roadmap/archive/phase/<phase-slug>/...` | 완료 또는 폐기되어 현재 후보에서 제외한 과거 Phase/Milestone. 일반 작업에서는 읽지 않는다 |
|
||||
|
||||
## 템플릿
|
||||
|
|
@ -70,7 +70,7 @@ agent-ops/
|
|||
- 기본 작성 언어는 한국어다.
|
||||
- 상태 표기는 `[스케치]`, `[계획]`, `[진행중]`, `[검토중]`, `[완료]`, `[보류]`, `[폐기]` 중 하나만 사용한다.
|
||||
- `[스케치]`는 방향성, 문제의식, 후보 범위, 미정 질문을 기록하는 컨셉 상태다. 구현 가능한 계획이 아니므로 구현 계획 생성 대상이 아니다.
|
||||
- `[계획]`은 목표, 범위, 완료 기준, 구현 잠금, 결정 필요 항목이 정리되어 구현 계획을 만들 수 있는 상태다.
|
||||
- `[계획]`은 목표, 범위, 기능 Task, 구현 잠금, 결정 필요 항목이 정리되어 구현 계획을 만들 수 있는 상태다.
|
||||
- Phase와 Milestone 이름, 파일명에는 `1`, `2`, `M01`, `P1` 같은 순번을 붙이지 않는다.
|
||||
- 진행 순서는 `ROADMAP.md`와 각 `PHASE.md`의 위에서 아래 순서로 표현한다.
|
||||
- Phase 파일명은 `agent-ops/roadmap/phase/<phase-slug>/PHASE.md`로 만든다.
|
||||
|
|
@ -80,19 +80,19 @@ agent-ops/
|
|||
|
||||
## Milestone 작성 규칙
|
||||
|
||||
- Milestone 기본 섹션은 `위치`, `목표`, `상태`, `구현 잠금`, `범위`, `필수 기능`, `완료 기준`, `완료 리뷰`, `범위 제외`, `작업 컨텍스트`다.
|
||||
- Milestone 기본 섹션은 `위치`, `목표`, `상태`, `구현 잠금`, `범위`, `기능`, `완료 리뷰`, `범위 제외`, `작업 컨텍스트`다.
|
||||
- `승격 조건`은 `[스케치]` Milestone에서 필수다. `[계획]` 이상 상태에서는 섹션을 생략하거나 `- 없음`으로 둘 수 있다.
|
||||
- `[스케치]` Milestone은 `승격 조건`을 체크리스트로 작성하고, `[계획]`으로 전환하기 위해 필요한 정의, 결정, 경계, 후속 구현 Milestone 후보를 적는다.
|
||||
- 새 Milestone은 사용자만 결정할 수 있는 제품 방향, 범위, 우선순위, 책임 경계가 남아 있으면 `구현 잠금`을 `잠금`으로 둔다.
|
||||
- 새 `[스케치]` Milestone은 `구현 잠금`을 `잠금`으로 둔다.
|
||||
- Milestone 전체에서 사용자만 결정할 항목이 더 이상 없고 에이전트가 표준선에 따라 실행하면 되는 상태라면 `해제`로 둔다.
|
||||
- `구현 잠금`에는 상태와 `결정 필요` 체크리스트만 적는다. 결정할 항목이 없으면 `결정 필요: 없음`으로 적는다.
|
||||
- `필수 기능`은 Epic heading과 Task 체크리스트로 작성한다.
|
||||
- `기능`은 Epic heading과 Task 체크리스트로 작성한다.
|
||||
- Epic heading은 `### Epic: [epic-id] <이름>` 형식으로 작성한다.
|
||||
- Task는 `- [ ] [item-id] 설명` 형식으로 작성한다.
|
||||
- epic-id와 item-id는 공백 없는 짧은 ASCII 토큰이며, 해당 Milestone 안에서만 유일하면 된다.
|
||||
- `완료 기준`은 검증 가능한 조건의 체크리스트로 작성한다.
|
||||
- `완료 리뷰`는 새 Milestone에서는 `상태: 없음`, `요청일: 없음`으로 두고, 모든 필수 Task와 완료 기준이 충족된 뒤 사용자 최종 확인을 요청할 때 갱신한다.
|
||||
- 검증이 필요한 Task에만 같은 항목 안에 `검증: <명령/확인 방법/기대 결과>`를 붙인다. 검증이 필요 없는 기능에는 억지 검증을 붙이지 않는다.
|
||||
- `완료 리뷰`는 새 Milestone에서는 `상태: 없음`, `요청일: 없음`으로 두고, 모든 기능 Task와 Task 안에 명시된 검증이 충족된 뒤 사용자 최종 확인을 요청할 때 갱신한다.
|
||||
- `범위`, `범위 제외`, `작업 컨텍스트`는 설명 목록으로 작성하고, 실행해야 할 작업을 이 섹션에 숨기지 않는다.
|
||||
|
||||
## 먼저 확인할 것
|
||||
|
|
@ -119,7 +119,7 @@ agent-ops/
|
|||
- 전체 목표는 프로젝트가 궁극적으로 만들려는 결과를 1~3문장으로 작성한다.
|
||||
- Phase는 큰 진화 단위로 나누고, 각 Phase에 목표와 상태를 둔다.
|
||||
- Milestone은 Phase 안에서 완료 판단이 가능한 단위로 나눈다.
|
||||
- Milestone 내부에서 하위 작업 묶음이 필요하면 Epic으로 선언하고, Epic 아래 Task 체크리스트를 둔다.
|
||||
- Milestone 내부에서 여러 기능 묶음이 필요하면 Epic으로 선언하고, Epic 아래 flat Task 체크리스트를 둔다.
|
||||
|
||||
4. **파일 생성**
|
||||
- `ROADMAP.md`, `current.md`, 각 Phase의 `PHASE.md`, 각 Milestone 문서를 템플릿 순서대로 생성한다.
|
||||
|
|
|
|||
|
|
@ -136,12 +136,15 @@ If a selected task directory contains both `USER_REVIEW.md` and active `PLAN-*-G
|
|||
- `agent-ops/roadmap/current.md`가 있으면 구현 계획 파일을 만들기 전에 읽고, 사용자 요청, 브랜치, 변경 경로를 기준으로 관련 Phase와 Milestone을 선택한다.
|
||||
- `current.md`가 `agent-ops/roadmap/archive/**`를 가리키면 해당 문서는 읽지 말고 활성 Phase/Milestone이 아니라고 보고한다.
|
||||
- 선택한 Phase를 한 번 읽어 Phase 목표, Milestone 흐름, Phase 경계를 확인한다.
|
||||
- 선택한 Milestone을 한 번 읽어 목표, 상태, 승격 조건, 범위, 필수 기능, 완료 기준, 완료 리뷰, 범위 제외, 구현 잠금을 확인한다. `승격 조건`은 `[스케치]`에서만 필수이며, `[계획]` 이상에서 섹션이 없으면 `없음`으로 본다. `구현 잠금` 섹션이 없거나 상태가 `잠금`이면 현재 요청에 직접 영향을 주는 `결정 필요` 항목만 확인하고, 그 결정 없이는 `PLAN-*-G??.md`, `CODE_REVIEW-*-G??.md`, file/API/package 수준 구현 단계를 확정하지 않는다.
|
||||
- 선택한 Phase 또는 Milestone 상태가 `[스케치]`이면 구현 계획 파일을 만들지 않는다. `[스케치]`는 컨셉 상태이므로 `update-roadmap`의 concretize 흐름으로 승격 조건, 결정 필요, 범위, 완료 기준을 정리해 `[계획]`으로 전환해야 한다고 보고한다.
|
||||
- 선택한 Milestone을 한 번 읽어 목표, 상태, 승격 조건, 범위, 기능 Task, 완료 리뷰, 범위 제외, 구현 잠금을 확인한다. `승격 조건`은 `[스케치]`에서만 필수이며, `[계획]` 이상에서 섹션이 없으면 `없음`으로 본다. `구현 잠금` 섹션이 없거나 상태가 `잠금`이면 현재 요청에 직접 영향을 주는 `결정 필요` 항목만 확인하고, 그 결정 없이는 `PLAN-*-G??.md`, `CODE_REVIEW-*-G??.md`, file/API/package 수준 구현 단계를 확정하지 않는다.
|
||||
- 선택한 Milestone에 legacy `필수 기능`/`완료 기준`이 분리되어 있으면 plan 작성 전에 roadmap preflight로 정규화한다. 흡수 가능한 기준은 관련 기능 Task 안의 선택적 `검증:` 또는 Task 설명으로 즉시 흡수하고, 어느 기능에도 붙지 않는 기준이 남으면 plan 파일을 만들지 말고 남은 기준과 필요한 사용자 판단을 구체적으로 보고한다.
|
||||
- 선택한 Phase 또는 Milestone 상태가 `[스케치]`이면 구현 계획 파일을 만들지 않는다. `[스케치]`는 컨셉 상태이므로 `update-roadmap`의 concretize 흐름으로 승격 조건, 결정 필요, 범위, 기능 Task를 정리해 `[계획]`으로 전환해야 한다고 보고한다.
|
||||
- Phase 또는 Milestone 후보가 여럿이면 요청 문장, 변경 경로 직접성, Milestone 상태, 구현 잠금, 선후 의존성, Phase/Milestone 흐름상 위치를 기준으로 1순위와 2순위를 추천하고 필요한 후보 문서만 읽어 범위를 좁힌다.
|
||||
- 로드맵 current가 있고 활성 Phase/Milestone 밖 작업이면 `ROADMAP.md`의 Phase 흐름을 확인하고 전환, 신규 Phase/Milestone, 또는 기존 활성 범위 내 배치 필요성을 보고한다.
|
||||
- 현재 요청과 직접 관련 없는 미정 항목은 잠금 상태로 남겨도 되며, 기존 구조, 도메인 rule, 플랫폼 관례로 정할 수 있는 세부는 표준선/가정으로 계획에 기록하고 진행할 수 있다.
|
||||
- 사용자가 선택한 Milestone의 작업, 구현, 계획 작성을 명시했고 현재 계획에 필요한 결정이 모두 정해져 있다면 계획 작성을 이어간다. Milestone 전체에서 사용자만 결정할 항목이 더 이상 없을 때만 roadmap update 흐름으로 `구현 잠금` 상태를 `해제`로 갱신한다. 현재 요청에 직접 걸리는 결정이 필요하면 그 항목만 체크리스트로 남기고 사용자에게 확인한다.
|
||||
- 사용자 검토, 제품 선택, 우선순위 결정처럼 사용자가 해야 하는 항목은 구현 계획의 실행 checklist로 쓰지 않는다. 현재 구현에 직접 필요하면 plan 생성을 멈추고 `결정 필요`로 남기며, 직접 필요하지 않으면 `작업 컨텍스트`나 `범위 결정 근거`에만 기록한다.
|
||||
- 기능 Task에 `검증:`이 있으면 구현 계획의 같은 plan item 안에 해당 검증을 포함한다. 검증이 명시되지 않은 기능 Task에는 억지 검증 항목을 만들지 말고, 필요한 일반 빌드/회귀 확인만 최종 검증에 둔다.
|
||||
- 선택한 활성 Milestone 범위에 속하는 구현 계획이면 `{task_group}`을 `m-<milestone-slug>`로 정한다. `<milestone-slug>`는 선택한 Milestone 경로의 파일명에서 `.md`를 제거한 값이다.
|
||||
- 같은 Milestone에서 split work가 필요하면 기존 split 규칙 그대로 `agent-task/m-<milestone-slug>/<subtask_dir>/` 아래에 계획 파일을 만든다.
|
||||
- roadmap/current 파일이 없으면 기존 task routing 규칙대로 진행한다.
|
||||
|
|
@ -212,7 +215,7 @@ Required sections:
|
|||
- `분할 판단`: state that the split decision policy was evaluated before choosing plan files. For a single plan, explain why each relevant split gate does not apply and why single-plan coordination is safer than splitting. For multi-plan output, list the shared task group plus each sibling subtask directory and dependency relationship.
|
||||
- `범위 결정 근거`: state which files or areas were explicitly excluded from this change and why. This is the boundary justification — the implementing agent must not silently expand scope beyond what is recorded here.
|
||||
- `빌드 등급`: state the decided lane and GNN grade with a one-line rationale.
|
||||
- `구현 체크리스트`: a top-level checklist the implementing agent must follow while coding. Include one item per plan item, one item for all intermediate/final verification, and make the final item exactly: `- [ ] CODE_REVIEW-*-G??.md의 구현 에이전트 소유 섹션을 실제 구현 내용과 검증 출력으로 채운다. 이 항목이 완료되기 전에는 구현이 완료된 것이 아니다.` Copy this checklist into the review stub's `구현 체크리스트` section with the same item text and order.
|
||||
- `구현 체크리스트`: a top-level checklist the implementing agent must follow while coding. Include one item per implementation/verification unit; if the roadmap feature Task has `검증:`, keep that verification in the same checklist item instead of making a separate completion-criteria item. Include one item for whole-plan intermediate/final verification only when it is not already covered by the feature items, and make the final item exactly: `- [ ] CODE_REVIEW-*-G??.md의 구현 에이전트 소유 섹션을 실제 구현 내용과 검증 출력으로 채운다. 이 항목이 완료되기 전에는 구현이 완료된 것이 아니다.` Copy this checklist into the review stub's `구현 체크리스트` section with the same item text and order.
|
||||
- One item per change: `### [TAG-1] Title`, `TAG-2`, etc.
|
||||
- `수정 파일 요약`: table mapping files to item ids.
|
||||
- `최종 검증`: runnable commands and expected outcome. Commands must be exact and deterministic enough for the reviewer to rerun; use stable ordering for searches and state whether cached test output is acceptable. The final line of this section must read exactly — **"모든 코드 변경 완료 후 반드시 `CODE_REVIEW-*-G??.md`의 구현 에이전트 소유 섹션을 채운다. 이 파일 작성이 구현의 마지막 단계다."**
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
name: update-roadmap
|
||||
version: 1.18.1
|
||||
version: 1.19.0
|
||||
description: 로드맵 업데이트, 로드맵에 추가, 마일스톤 추가/갱신, phase/페이즈 변경 요청에 사용한다. Roadmap-Phase-Milestone scaffold에서 target 없는 신규 작업의 규모를 판정하고 기존 Phase/Milestone/Epic/Task를 검색해 upsert한 뒤, 없을 때만 새 항목을 만들고 current.md 동기화, runtime m-task 완료 이벤트 반영, 완료 후보 검토중 전환, 승인된 archive 이동을 처리한다.
|
||||
---
|
||||
|
||||
|
|
@ -14,7 +14,7 @@ archive도 같은 Phase scaffold를 유지하며 `archive/phase/<phase-slug>/...
|
|||
로드맵 전체를 매 작업마다 읽지 않도록 유지하면서, `current.md`의 활성 Phase와 활성 Milestone 창이 실제 작업 후보 목록으로 동작하게 한다.
|
||||
|
||||
Milestone은 구현 계획이 아니라 방향성, 범위, 위험, 확인 필요 사항을 기록하는 협업 문서로 유지한다.
|
||||
Epic과 Task는 별도 파일로 분리하지 않고 Milestone 문서의 `필수 기능` 안에서 관리한다.
|
||||
Epic과 Task는 별도 파일로 분리하지 않고 Milestone 문서의 `기능` 안에서 관리한다. 별도 `완료 기준` 섹션은 만들지 않고, 검증이 필요한 기능에만 같은 Task 안의 `검증:` 문구로 통합한다.
|
||||
|
||||
## 언제 호출할지
|
||||
|
||||
|
|
@ -84,9 +84,9 @@ agent-ops/roadmap/
|
|||
- `[스케치]`는 방향성, 문제의식, 후보 범위, 미정 질문을 기록하는 컨셉 상태다. 구현 가능한 계획이 아니므로 `agent-task` 구현 계획 생성과 코드 구현 대상으로 삼지 않는다.
|
||||
- `[스케치]` 항목은 `[계획]`으로 승격하기 위한 `승격 조건`, 사용자 결정, 범위 경계, 후속 Milestone 후보를 정리한다.
|
||||
- `[계획]` 이상 Milestone에서 `승격 조건` 섹션은 선택 사항이다. 섹션이 없거나 `- 없음`이면 템플릿 오류로 보지 않는다.
|
||||
- `[스케치]`를 `[계획]`으로 전환할 때는 `승격 조건`의 미정 항목이 해소되고, 목표, 범위, 완료 기준, 직접적인 사용자 결정 항목, 후속 구현 단위가 구현 계획을 만들 수 있을 만큼 정리되었는지 확인한다.
|
||||
- `[계획]`은 목표, 범위, 완료 기준, 구현 잠금, 결정 필요 항목이 정리되어 구현 계획을 만들 수 있는 상태다.
|
||||
- `[검토중]`은 모든 필수 작업과 완료 기준이 충족된 것으로 보이나, 사용자 최종 확인과 archive 승인이 남은 완료 후보 상태다.
|
||||
- `[스케치]`를 `[계획]`으로 전환할 때는 `승격 조건`의 미정 항목이 해소되고, 목표, 범위, 기능 Task, 직접적인 사용자 결정 항목, 후속 구현 단위가 구현 계획을 만들 수 있을 만큼 정리되었는지 확인한다.
|
||||
- `[계획]`은 목표, 범위, 기능 Task, 구현 잠금, 결정 필요 항목이 정리되어 구현 계획을 만들 수 있는 상태다.
|
||||
- `[검토중]`은 모든 기능 Task와 Task 안에 명시된 검증이 충족된 것으로 보이나, 사용자 최종 확인과 archive 승인이 남은 완료 후보 상태다.
|
||||
- 검토 결과 보완이 필요하면 별도 reopen 상태를 만들지 않고 `[진행중]`으로 되돌린 뒤 `완료 리뷰` 또는 `작업 컨텍스트`에 보완 방향을 남긴다.
|
||||
- 검토 결과 보류 또는 폐기 결정이 나면 `[보류]` 또는 `[폐기]`로 전환한다.
|
||||
- `ROADMAP.md`의 Phase 흐름과 `PHASE.md`의 Milestone 흐름은 완료, 검토중, 진행중, 계획, 스케치 순서를 기본으로 하며 아래로 갈수록 미래 작업에 가까워지게 정렬한다.
|
||||
|
|
@ -116,12 +116,12 @@ agent-ops/roadmap/
|
|||
- 사용자만 결정할 수 있는 제품 방향, 범위, 우선순위, 책임 경계가 남아 있으면 `잠금`으로 두고 `결정 필요` 체크리스트에 질문을 적는다.
|
||||
- 기존 구조, 도메인 rule, 플랫폼 관례, 업계 표준으로 합리적으로 정할 수 있는 항목은 `결정 필요`가 아니라 `작업 컨텍스트`의 표준선으로 기록한다.
|
||||
- Milestone 전체에서 사용자만 결정할 항목이 더 이상 없고 에이전트가 표준선에 따라 실행하면 되는 상태라면 `해제`로 둔다.
|
||||
- 잠금 상태 변경은 Milestone 완료 판정이 아니므로 `필수 기능`과 `완료 기준`을 자동 완료 처리하지 않는다.
|
||||
- 잠금 상태 변경은 Milestone 완료 판정이 아니므로 `기능` Task를 자동 완료 처리하지 않는다.
|
||||
- `[스케치]` Milestone은 `구현 잠금`이 `해제`로 보이더라도 구현 계획과 코드 구현 대상이 아니다. 먼저 승격 조건을 충족해 `[계획]`으로 전환한다.
|
||||
|
||||
## 완료 리뷰와 검토중 상태
|
||||
|
||||
- Task 완료 또는 Milestone 갱신 후 필수 Epic/Task와 `완료 기준`이 모두 evidence와 함께 `[x]`인지 확인한다.
|
||||
- Task 완료 또는 Milestone 갱신 후 모든 기능 Task와 Task 안에 명시된 검증이 evidence와 함께 `[x]`인지 확인한다.
|
||||
- 모두 충족된 것으로 보이면 Milestone을 `[완료]`로 바로 바꾸거나 archive로 이동하지 말고 `[검토중]`으로 바꾼다.
|
||||
- `[검토중]`으로 바꿀 때는 Milestone 문서의 `완료 리뷰` 섹션을 만들거나 갱신한다.
|
||||
- `완료 리뷰`에는 `상태: 요청됨`, `요청일`, 완료 근거 1~3줄, 사용자 최종 확인 항목, 리뷰 코멘트를 남긴다.
|
||||
|
|
@ -135,8 +135,8 @@ agent-ops/roadmap/
|
|||
- 런타임 완료 이벤트의 `origin-task`에서 `agent-task/` 다음 첫 path segment가 `m-<milestone-slug>`이면 Milestone 기반 plan/review 완료에서 온 요청으로 본다. `origin-task`는 archive 이동 전 active task 경로 또는 런타임이 그 형태로 정규화한 경로를 사용한다.
|
||||
- `<milestone-slug>`는 활성 `agent-ops/roadmap/phase/*/milestones/<milestone-slug>.md`에서 정확히 하나만 찾아야 한다. archive Milestone은 target 후보가 아니다.
|
||||
- target이 없거나 둘 이상이면 Milestone 내용을 추정해 수정하지 말고 target 불명확으로 보고한다.
|
||||
- target이 확정되면 PASS evidence, `complete.log`, final archive path, archived plan/review log 경로, code-review 결과 요약을 근거로 해당 Milestone의 Epic/Task와 완료 기준을 갱신한다. target routing 자체는 완료 이벤트의 `m-<milestone-slug>` task group으로만 결정한다.
|
||||
- 갱신 후 필수 Epic/Task와 완료 기준이 모두 충족되면 `[검토중]` 전환과 `완료 리뷰` 요청 규칙을 적용한다.
|
||||
- target이 확정되면 PASS evidence, `complete.log`, final archive path, archived plan/review log 경로, code-review 결과 요약을 근거로 해당 Milestone의 기능 Task를 갱신한다. target routing 자체는 완료 이벤트의 `m-<milestone-slug>` task group으로만 결정한다.
|
||||
- 갱신 후 모든 기능 Task와 Task 안에 명시된 검증이 충족되면 `[검토중]` 전환과 `완료 리뷰` 요청 규칙을 적용한다.
|
||||
- target Milestone이 `[스케치]`이면 완료 이벤트를 반영하지 말고 상태 불일치로 보고한다. `[스케치]`는 Milestone 기반 `agent-task` 완료 이벤트의 target이 될 수 없다.
|
||||
|
||||
## 삽입 단위 정책
|
||||
|
|
@ -144,20 +144,20 @@ agent-ops/roadmap/
|
|||
| 삽입 단위 | 사용 기준 |
|
||||
|-----------|-----------|
|
||||
| 새 Phase | 독립적인 제품 진화 단계와 여러 Milestone 묶음이 필요하다 |
|
||||
| 새 Milestone | 독립적인 목표와 완료 기준이 필요하고 Phase 흐름에 의미 있는 경계를 만든다 |
|
||||
| 새 Milestone | 독립적인 목표와 기능 Task 묶음이 필요하고 Phase 흐름에 의미 있는 경계를 만든다 |
|
||||
| 새 Epic | 기존 Milestone 안에서 여러 Task를 묶는 상위 capability 또는 산출물이다 |
|
||||
| 새 Task | 기존 Epic 아래에 들어가는 완료 가능한 capability, 산출물, 검증 항목이다 |
|
||||
| 하위 작업 | 기존 Task를 완성하기 위한 구현 세부, 테스트, 문서화, 예외 처리다 |
|
||||
| 작업 컨텍스트/TODO | 사용자 결정 또는 조사/확인이 먼저 필요해 필수 기능으로 확정하기 어렵다 |
|
||||
| 새 Task | 기존 Epic 아래에 들어가는 완료 가능한 capability 또는 산출물이다. 검증이 필요한 경우에만 같은 Task 안에 붙인다 |
|
||||
| 하위 작업 | 기존 Task를 완성하기 위한 구현 세부다. Milestone `기능`에는 하위 체크박스로 만들지 않고, plan 내부 체크리스트나 기존 Task의 `검증:`/설명 보강으로 다룬다 |
|
||||
| 작업 컨텍스트/TODO | 사용자 결정 또는 조사/확인이 먼저 필요해 기능 Task로 확정하기 어렵다 |
|
||||
|
||||
- 먼저 요청 내용의 규모를 판정한다. 배치 위치를 찾기 전에 `phase`, `milestone`, `epic`, `task`, `subtask`, `context` 중 가장 작은 충분한 단위를 고른다.
|
||||
- 요청이 방향성, 문제의식, 컨셉, 운영 원칙 수준이고 완료 기준이나 실행 범위가 아직 부족하면 새 항목의 상태는 `[스케치]`로 둔다.
|
||||
- 요청이 방향성, 문제의식, 컨셉, 운영 원칙 수준이고 기능 Task나 실행 범위가 아직 부족하면 새 항목의 상태는 `[스케치]`로 둔다.
|
||||
- `[스케치]` Phase/Milestone을 만들 때는 `승격 조건`에 `[계획]`으로 전환하기 위해 필요한 정의, 결정, 경계, 후속 구현 Milestone 후보를 체크리스트로 남긴다.
|
||||
- 가장 작은 충분한 단위 원칙을 따른다. 애매하면 새 Phase나 새 Milestone으로 키우지 말고, 기존 Milestone의 Epic/Task에 넣을 수 있는지 먼저 확인한다.
|
||||
- 위치 지정이 있으면 anchor의 레벨을 먼저 확인한다.
|
||||
- `<epic-id> 아래`는 해당 Epic 아래 Task로 넣는다.
|
||||
- `<item-id> 앞/뒤`는 같은 Epic 안의 형제 Task로 넣는다.
|
||||
- `<item-id> 아래`는 해당 Task의 하위 작업으로 넣는다.
|
||||
- `<item-id> 아래`는 해당 Task의 설명 또는 `검증:`을 보강한다. 구현 세부나 테스트만 따로 떼어낸 하위 체크박스는 Milestone `기능` 아래에 만들지 않는다.
|
||||
- `<phase-name> 안`은 새 Milestone 또는 기존 Milestone/Epic/Task 중 작업 성격에 맞는 단위로 배치한다.
|
||||
- 위치 지정이 없으면 `auto`로 본다. `current.md`의 활성 창만으로 결정하지 않고, 필요한 경우 `ROADMAP.md`의 Phase 흐름까지 확인해 완료/검토중/진행중/계획/스케치 Phase를 비교한다.
|
||||
- target 없는 신규 추가 요청은 요청 문장, 관련 파일/도메인 힌트, Phase 목표, Milestone 목표, 기존 Epic/Task, 선후 의존성, 상태, 활성 창을 비교해 가장 자연스러운 위치를 자동 판단한다.
|
||||
|
|
@ -176,24 +176,24 @@ target 없는 신규 추가 요청은 append가 아니라 upsert로 처리한다
|
|||
|
||||
2. **규모 판정**
|
||||
- 여러 Milestone을 묶는 제품/운영 단계면 Phase 규모다.
|
||||
- 독립 목표, 별도 완료 기준, 여러 Epic이 필요한 결과면 Milestone 규모다.
|
||||
- 컨셉은 충분히 크지만 구현 가능한 목표/범위/완료 기준이 아직 없으면 `[스케치]` Phase 또는 Milestone 후보로 둔다.
|
||||
- 독립 목표, 기능 Task 묶음, 여러 Epic이 필요한 결과면 Milestone 규모다.
|
||||
- 컨셉은 충분히 크지만 구현 가능한 목표/범위/기능 Task가 아직 없으면 `[스케치]` Phase 또는 Milestone 후보로 둔다.
|
||||
- 한 Milestone 안의 capability 묶음이면 Epic 규모다.
|
||||
- Epic 아래에서 완료 가능한 단일 capability, 산출물, 검증 항목이면 Task 규모다.
|
||||
- Task를 완성하기 위한 구현 세부면 subtask 규모다.
|
||||
- Epic 아래에서 완료 가능한 단일 capability 또는 산출물이면 Task 규모다. 검증이 필요한 경우에만 같은 Task 안에 포함한다.
|
||||
- Task를 완성하기 위한 구현 세부면 subtask 규모다. roadmap에는 하위 체크박스로 기록하지 않고, 구현 계획 내부 또는 기존 Task 보강으로 처리한다.
|
||||
- 조사, 결정, 보류 질문이면 작업 컨텍스트/TODO 규모다.
|
||||
|
||||
3. **레벨별 탐색**
|
||||
- Phase 후보를 먼저 찾는다. `current.md`의 활성 Phase를 우선 보되, target이 없거나 활성 범위 밖 가능성이 있으면 `ROADMAP.md`의 Phase 흐름도 본다.
|
||||
- 선택한 Phase 안에서 Milestone 후보를 찾는다. 활성 Milestone을 우선 보되, 요청이 계획 Milestone 목표와 더 직접 맞으면 계획 Milestone도 후보로 둔다.
|
||||
- 선택한 Milestone 안에서 Epic 후보를 찾는다. `필수 기능`의 Epic heading, 목표 설명, Task 묶음을 비교한다.
|
||||
- 선택한 Epic 안에서 Task 후보를 찾는다. item-id, 문장 의미, 완료 기준, 관련 경로를 비교한다.
|
||||
- 선택한 Milestone 안에서 Epic 후보를 찾는다. `기능`의 Epic heading, 목표 설명, Task 묶음을 비교한다. 기존 문서가 `필수 기능`을 쓰면 갱신 시 `기능`으로 정규화한다.
|
||||
- 선택한 Epic 안에서 Task 후보를 찾는다. item-id, 문장 의미, Task 안의 검증 문구, 관련 경로를 비교한다.
|
||||
- archive 문서는 기본 탐색 대상이 아니다. 사용자가 과거 기록 비교를 명시했거나 완료 내용 확인이 필요한 경우에만 `ROADMAP.md` 또는 `PHASE.md`의 archive 링크를 따라 필요한 문서만 읽는다.
|
||||
|
||||
4. **중복/업데이트 판정**
|
||||
- 같은 id, 같은 제목, 같은 목표, 같은 관련 경로, 같은 완료 기준, 또는 같은 산출물을 다루면 동일/유사 후보로 본다.
|
||||
- 같은 id, 같은 제목, 같은 목표, 같은 관련 경로, 같은 Task 안의 검증 문구, 또는 같은 산출물을 다루면 동일/유사 후보로 본다.
|
||||
- 동일 항목이면 새로 만들지 않고 기존 Phase/Milestone/Epic/Task를 업데이트한다.
|
||||
- 기존 항목의 범위를 보강하는 내용이면 해당 항목의 설명, Task, 완료 기준, 작업 컨텍스트 중 알맞은 곳에 병합한다.
|
||||
- 기존 항목의 범위를 보강하는 내용이면 해당 항목의 설명, Task 안의 검증 문구, 작업 컨텍스트 중 알맞은 곳에 병합한다.
|
||||
- 기존 항목과 충돌하거나 범위 제외를 건드리면 수정 전에 사용자에게 확인한다.
|
||||
- 같은 레벨에 적절한 후보가 없을 때만 새 항목을 만든다. 새 항목도 판정한 규모보다 크게 만들지 않는다.
|
||||
- 부모 레벨 후보는 있고 판정 규모의 항목만 없으면, 부모 아래에 판정 규모의 새 항목을 만든다. 부모 레벨도 없을 때만 필요한 부모 항목을 함께 만든다.
|
||||
|
|
@ -239,7 +239,7 @@ target 없는 신규 추가 요청은 append가 아니라 upsert로 처리한다
|
|||
- `current.md`의 활성 Phase와 활성 Milestone 후보를 확인한다.
|
||||
- target이 명시된 경우 대상 Phase의 `PHASE.md`를 읽고 Milestone 흐름과 Phase 경계를 확인한다.
|
||||
- target이 없거나 활성 창 밖 배치 가능성이 있으면 `ROADMAP.md`의 Phase 흐름을 확인하고, 관련성이 높은 Phase 문서를 읽는다.
|
||||
- 대상 또는 후보 Milestone 문서의 목표, 상태, 승격 조건, 범위, 필수 기능, 완료 기준, 완료 리뷰, 범위 제외, 구현 잠금을 확인한다.
|
||||
- 대상 또는 후보 Milestone 문서의 목표, 상태, 승격 조건, 범위, 기능 Task, 완료 리뷰, 범위 제외, 구현 잠금을 확인한다. 기존 문서에 `필수 기능`/`완료 기준`이 분리되어 있으면 갱신 범위에서 `기능` Task로 흡수할 후보를 기록한다.
|
||||
- Phase -> Milestone -> Epic -> Task 순서로 내려가며 같은 레벨의 동일/유사 후보를 먼저 찾는다.
|
||||
- `current.md`에 archive 경로가 있으면 읽지 말고 제거 대상으로 기록한다.
|
||||
- 필요한 경우에만 `ROADMAP.md`를 읽어 전체 Phase 흐름을 확인한다.
|
||||
|
|
@ -247,24 +247,24 @@ target 없는 신규 추가 요청은 append가 아니라 upsert로 처리한다
|
|||
4. **스케치 승격 판단**
|
||||
- `target-status=[계획]`, `mode=concretize`, 또는 사용자가 "구체화", "계획으로 올려"처럼 요청하면 `[스케치] -> [계획]` 승격 검토로 본다.
|
||||
- 대상이 `[스케치]`가 아니면 일반 상태 갱신이나 Milestone 갱신으로 처리한다.
|
||||
- 대상이 `[스케치]`이면 `승격 조건`, `구현 잠금`, `목표`, `범위`, `완료 기준`, `필수 기능`, `작업 컨텍스트`를 확인한다.
|
||||
- 대상이 `[스케치]`이면 `승격 조건`, `구현 잠금`, `목표`, `범위`, `기능`, `작업 컨텍스트`를 확인한다.
|
||||
- `승격 조건` 체크리스트가 남아 있거나 구현 계획에 직접 필요한 사용자 결정이 남아 있으면 상태를 `[스케치]`로 유지하고, 부족한 항목을 `승격 조건` 또는 `결정 필요`에 보강한다.
|
||||
- 구현 가능한 목표, 범위, 완료 기준, 직접 결정 항목, 후속 구현 단위가 정리되면 상태를 `[계획]`으로 전환하고, `승격 조건`은 충족 요약으로 남기거나 `- 없음`으로 정리한다.
|
||||
- 승격은 구현 완료가 아니므로 `필수 기능`과 `완료 기준`을 자동 완료 처리하지 않는다.
|
||||
- 구현 가능한 목표, 범위, 기능 Task, 직접 결정 항목, 후속 구현 단위가 정리되면 상태를 `[계획]`으로 전환하고, `승격 조건`은 충족 요약으로 남기거나 `- 없음`으로 정리한다.
|
||||
- 승격은 구현 완료가 아니므로 `기능` Task를 자동 완료 처리하지 않는다.
|
||||
|
||||
5. **변경 내용 작성**
|
||||
- `ROADMAP.md`는 전체 목표, Phase 흐름, 로딩 정책이 바뀔 때만 수정한다.
|
||||
- `current.md`는 활성 Phase/Milestone 창이 바뀔 때 수정한다.
|
||||
- `PHASE.md`는 Phase 목표, 상태, Milestone 흐름, Phase 경계가 바뀔 때 수정한다.
|
||||
- Milestone 문서는 목표, 상태, 승격 조건, 구현 잠금, 범위, Epic/Task, 완료 기준, 완료 리뷰, 범위 제외, 작업 컨텍스트가 바뀔 때 수정한다.
|
||||
- Milestone 문서는 목표, 상태, 승격 조건, 구현 잠금, 범위, Epic/Task, Task 안의 검증 문구, 완료 리뷰, 범위 제외, 작업 컨텍스트가 바뀔 때 수정한다.
|
||||
- 동일/유사 후보가 있으면 기존 항목을 업데이트하고 중복 항목을 만들지 않는다.
|
||||
- 새 Milestone은 해당 Phase의 `milestones/` 아래에 만든다.
|
||||
- 새 `[스케치]` Milestone은 `승격 조건` 섹션을 포함하고 `구현 잠금`은 `잠금`으로 둔다.
|
||||
- 새 Epic은 `필수 기능` 아래 `### Epic: [epic-id] <이름>`으로 만든다.
|
||||
- 새 Task는 관련 Epic 아래 `- [ ] [item-id] 설명`으로 만든다.
|
||||
- 새 Epic은 `기능` 아래 `### Epic: [epic-id] <이름>`으로 만든다.
|
||||
- 새 Task는 관련 Epic 아래 `- [ ] [item-id] 설명`으로 만든다. 검증이 필요한 경우에만 같은 항목에 `검증: <명령/확인 방법/기대 결과>`를 붙인다.
|
||||
- 새 항목은 레벨별 탐색에서 적절한 기존 후보가 없을 때만 만든다.
|
||||
- 완료 체크는 evidence가 있을 때만 `[x]`로 바꾼다.
|
||||
- 필수 Epic/Task와 완료 기준이 모두 evidence와 함께 `[x]`이면 Milestone 상태를 `[검토중]`으로 바꾸고 `완료 리뷰`에 리뷰 요청과 근거를 남긴다.
|
||||
- 모든 기능 Task와 Task 안에 명시된 검증이 evidence와 함께 `[x]`이면 Milestone 상태를 `[검토중]`으로 바꾸고 `완료 리뷰`에 리뷰 요청과 근거를 남긴다.
|
||||
- `[검토중]` 전환만으로 archive 이동, `current.md` 제거, archive 링크 변경을 수행하지 않는다.
|
||||
- 사용자 승인 근거가 있으면 `[검토중]`을 `[완료]`로 전환하고 archive 모드를 수행할 수 있다.
|
||||
|
||||
|
|
@ -279,7 +279,7 @@ target 없는 신규 추가 요청은 append가 아니라 upsert로 처리한다
|
|||
- `[계획]` 이상 Milestone에 `승격 조건` 섹션이 없더라도 오류로 보지 않는다. 섹션이 있으면 `- 없음` 또는 승격 충족 요약인지 확인한다.
|
||||
- `[스케치] -> [계획]` 전환을 수행했다면 승격 조건 해소 근거가 Milestone 내용이나 결과 보고에 남았는지 확인한다.
|
||||
- `[검토중]` Milestone이 archive 경로로 이동되지 않았는지 확인한다.
|
||||
- 필수 Epic/Task와 완료 기준이 모두 `[x]`인 Milestone에는 `완료 리뷰` 섹션과 사용자 리뷰 요청이 있는지 확인한다.
|
||||
- 모든 기능 Task와 Task 안에 명시된 검증이 `[x]`인 Milestone에는 `완료 리뷰` 섹션과 사용자 리뷰 요청이 있는지 확인한다.
|
||||
- Epic heading과 Task id 형식이 맞는지 확인한다.
|
||||
- 요청 규모가 판정되었고 결과 보고에 남았는지 확인한다.
|
||||
- 동일/유사 기존 항목을 검색했고 신규/업데이트 판정이 결과 보고에 남았는지 확인한다.
|
||||
|
|
|
|||
Loading…
Reference in a new issue