update roadmap and services core readme
This commit is contained in:
parent
534c9000da
commit
33e02c7063
8 changed files with 71 additions and 107 deletions
|
|
@ -29,7 +29,7 @@ NomadCode는 Flutter 기반 앱, core 서비스, 공유 계약, agent-operation
|
|||
- 요약: Flutter 앱에 섞인 Mattermost push notification migration을 분리했고, 현재 package 경로는 `../nexo/packages/messaging_flutter`다.
|
||||
- [진행중] Workflow Core
|
||||
- 경로: `agent-roadmap/phase/workflow-core/PHASE.md`
|
||||
- 요약: Roadmap Driven Agent-Ops Automation 스케치를 먼저 구체화한 뒤 실제 e2e 흐름을 기준으로 task lifecycle, retry, timeout, notification event를 안정화한다.
|
||||
- 요약: Roadmap Driven Agent-Ops Automation을 NomadCode Core와 MCP-first 제어 표면 방향으로 정리한 뒤 실제 e2e 흐름을 기준으로 task lifecycle, retry, timeout, notification event를 안정화한다.
|
||||
- [계획] External Integration
|
||||
- 경로: `agent-roadmap/phase/external-integration/PHASE.md`
|
||||
- 요약: Plane 확장, Mattermost, Agent Integrator, IOP OpenAI API Responses-compatible 호출을 실제 통합 흐름으로 확장한다.
|
||||
|
|
@ -49,8 +49,8 @@ NomadCode는 Flutter 기반 앱, core 서비스, 공유 계약, agent-operation
|
|||
- 요청 내용, 현재 브랜치, 변경 파일, 관련 코드 경로를 보고 가장 관련 있는 활성 Phase와 Milestone 문서를 같은 세션에서 1회 읽는다.
|
||||
- 활성 Phase 또는 Milestone 밖의 작업이면 이 문서의 Phase 흐름을 확인하고 사용자에게 진행 또는 전환 여부를 확인한다.
|
||||
- 이 문서는 로드맵 생성/갱신, Phase 전환, Phase 추가/수정, 전체 구조 변경 요청이 있을 때만 읽는다.
|
||||
- 상세 작업과 완료 기준은 각 Milestone 문서의 `필수 기능`, `완료 기준`으로 관리한다.
|
||||
- 모든 필수 작업과 완료 기준이 충족된 Milestone은 먼저 `[검토중]`으로 두고, 사용자 완료 확인과 archive 승인을 받은 뒤 `[완료]`로 전환한다.
|
||||
- 상세 작업은 각 Milestone 문서의 `기능`으로 관리한다. 검증이 필요한 기능만 같은 Task 안에 `검증:`으로 통합한다.
|
||||
- 모든 기능 Task와 Task 안에 명시된 검증이 충족된 Milestone은 먼저 `[검토중]`으로 두고, 사용자 완료 확인과 archive 승인을 받은 뒤 `[완료]`로 전환한다.
|
||||
- 완료된 Phase는 `agent-roadmap/archive/phase/<phase-slug>/PHASE.md`로 이동하고, 하위 Milestone도 같은 archive Phase scaffold 아래에 둔다.
|
||||
- 진행중 Phase 안에서 완료된 Milestone은 활성 Phase 문서에 짧은 링크를 남기고, 상세 문서는 `agent-roadmap/archive/phase/<phase-slug>/milestones/`로 이동한다.
|
||||
- archive `PHASE.md`는 Phase 자체가 완료 또는 폐기될 때만 만들며, 진행중 Phase의 완료 Milestone만 archive된 경우 archive Phase 디렉터리에 `milestones/`만 있을 수 있다.
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@
|
|||
|
||||
## 활성 Milestone
|
||||
|
||||
- [스케치] Roadmap Driven Agent-Ops Automation
|
||||
- [계획] Roadmap Driven Agent-Ops Automation
|
||||
- Phase: `agent-roadmap/phase/workflow-core/PHASE.md`
|
||||
- 경로: `agent-roadmap/phase/workflow-core/milestones/roadmap-driven-agent-ops-automation.md`
|
||||
- [계획] Workflow Core
|
||||
|
|
|
|||
|
|
@ -31,28 +31,19 @@ Work Item Provider Pipeline Design과 workflow core 이후 남은 Plane/Jira 확
|
|||
- IOP 외부 호출 표면은 OpenAI API 호환과 A2A만 전제하되, 현재 단계의 기본 호출은 OpenAI API Responses-compatible 경로로 한정
|
||||
- NomadCode core가 직접 모델 endpoint 또는 Ollama fallback을 기본 실행 경로로 전제하지 않도록 전환 기준 정리
|
||||
|
||||
## 필수 기능
|
||||
## 기능
|
||||
|
||||
### Epic: [external-integration] Provider and execution adapters
|
||||
|
||||
외부 work item provider, 협업 도구, 실행 표면을 adapter 경계 안에서 실제 통합 흐름으로 확장한다.
|
||||
|
||||
- [ ] [plane-adapter-expand] Plane issue 생성, comment, status update adapter 확장
|
||||
- [ ] [jira-adapter] Jira issue 조회, comment, status transition adapter 구현
|
||||
- [ ] [mattermost-adapter] Mattermost 메시지 발송 adapter 구현
|
||||
- [ ] [agent-integrator] Agent Integrator 호출 경계 정의
|
||||
- [x] [iop-responses] IOP OpenAI API Responses-compatible 경로를 NomadCode의 기본 실행 호출 경로로 정리
|
||||
- [x] [model-reclass] direct model endpoint / Ollama fallback 표현과 설정을 IOP 경유 호출 기준으로 재분류
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- [ ] core가 Plane에 issue, comment, status update를 요청할 수 있다.
|
||||
- [ ] core가 Jira에 issue 조회, comment, status transition을 요청할 수 있다.
|
||||
- [ ] core가 Mattermost에 메시지를 발송할 수 있다.
|
||||
- [ ] Agent Integrator 또는 그 대체 연결 지점이 명확히 정의되어 있다.
|
||||
- [x] IOP OpenAI API Responses-compatible 호출 경로가 core workflow와 연결된다.
|
||||
- [x] NomadCode의 기본 실행 경로가 직접 모델 호출이 아니라 IOP 경유 호출임이 로드맵과 운영 문서에서 일관되게 읽힌다.
|
||||
- [ ] 외부 provider별 세부 구현이 adapter 경계 밖으로 새지 않는다.
|
||||
- [ ] [plane-adapter-expand] Plane issue 생성, comment, status update adapter 확장. 검증: core가 Plane에 issue, comment, status update를 요청할 수 있다.
|
||||
- [ ] [jira-adapter] Jira issue 조회, comment, status transition adapter 구현. 검증: core가 Jira에 issue 조회, comment, status transition을 요청할 수 있다.
|
||||
- [ ] [mattermost-adapter] Mattermost 메시지 발송 adapter 구현. 검증: core가 Mattermost에 메시지를 발송할 수 있다.
|
||||
- [ ] [agent-integrator] Agent Integrator 호출 경계 정의. 검증: Agent Integrator 또는 그 대체 연결 지점이 명확히 정의되어 있다.
|
||||
- [x] [iop-responses] IOP OpenAI API Responses-compatible 경로를 NomadCode의 기본 실행 호출 경로로 정리. 검증: IOP OpenAI API Responses-compatible 호출 경로가 core workflow와 연결된다.
|
||||
- [x] [model-reclass] direct model endpoint / Ollama fallback 표현과 설정을 IOP 경유 호출 기준으로 재분류. 검증: NomadCode의 기본 실행 경로가 직접 모델 호출이 아니라 IOP 경유 호출임이 로드맵과 운영 문서에서 일관되게 읽힌다.
|
||||
- [ ] [adapter-boundary] 외부 provider별 구현 경계 점검. 검증: provider 세부 구현이 adapter 경계 밖으로 새지 않는다.
|
||||
|
||||
## 완료 리뷰
|
||||
|
||||
|
|
|
|||
|
|
@ -30,26 +30,18 @@ Flutter-first 클라이언트 구조 위에서 기존 Project/Session/Workspace
|
|||
- code-server, Agent Chat, task/execution state, 파일 변경 결과, diff/branch/commit/PR 흐름을 프로젝트 제어 화면에 배치하는 기준 정리
|
||||
- NomadCode Project/Session/Workspace 상태와 IOP 호출 결과를 사용자에게 보여주는 경계 정리
|
||||
|
||||
## 필수 기능
|
||||
## 기능
|
||||
|
||||
### Epic: [workspace-ux] Project workspace UX definition
|
||||
|
||||
Flutter-first 앱에서 project/session/workspace 제어 표면과 desktop/mobile 역할 경계를 정의한다.
|
||||
|
||||
- [ ] [common-capability] 프로젝트 단위 제어 화면의 공통 capability를 정의한다.
|
||||
- [ ] [mobile-tabs] mobile 상단탭 기반 프로젝트 관리 구조를 정의한다.
|
||||
- [ ] [desktop-tabs] Flutter 앱 desktop 탭 기반 프로젝트 관리 구조를 정의한다.
|
||||
- [ ] [desktop-window] Flutter 앱 desktop 프로젝트 단위 새창을 code-server와 Agent Chat을 포함한 프로젝트 제어 확장 표면으로 정의한다.
|
||||
- [ ] [parity] desktop은 mobile에서 가능한 프로젝트 관리 기능을 모두 포함한다는 parity 기준을 정한다.
|
||||
- [ ] [iop-result-ux] IOP OpenAI API Responses-compatible 호출 결과, task 상태, 파일 변경 결과를 UX에 표시하는 기준을 정한다.
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- [ ] 프로젝트 관리 UX에서 Flutter 앱 desktop layout, desktop project window, mobile top-tab의 역할이 충돌 없이 설명된다.
|
||||
- [ ] mobile에서 가능한 프로젝트 관리 기능이 desktop에도 포함된다는 기준이 문서화되어 있다.
|
||||
- [ ] 프로젝트 단위 새창이 단순 code-server 링크가 아니라 프로젝트 제어 확장 표면임이 문서화되어 있다.
|
||||
- [ ] IOP 실행 결과, task 상태, 파일 변경 결과가 NomadCode UX에서 어떻게 보이는지 최소 기준이 정리되어 있다.
|
||||
- [ ] 기존 Project/Session/Workspace 방향을 대체하지 않고 보강하는 Milestone으로 읽힌다.
|
||||
- [ ] [common-capability] 프로젝트 단위 제어 화면의 공통 capability를 정의한다. 검증: 기존 Project/Session/Workspace 방향을 대체하지 않고 보강하는 Milestone으로 읽힌다.
|
||||
- [ ] [mobile-tabs] mobile 상단탭 기반 프로젝트 관리 구조를 정의한다. 검증: mobile top-tab 역할이 desktop layout, desktop project window와 충돌 없이 설명된다.
|
||||
- [ ] [desktop-tabs] Flutter 앱 desktop 탭 기반 프로젝트 관리 구조를 정의한다. 검증: desktop layout 역할이 mobile top-tab, desktop project window와 충돌 없이 설명된다.
|
||||
- [ ] [desktop-window] Flutter 앱 desktop 프로젝트 단위 새창을 code-server와 Agent Chat을 포함한 프로젝트 제어 확장 표면으로 정의한다. 검증: 프로젝트 단위 새창이 단순 code-server 링크가 아니라 프로젝트 제어 확장 표면임이 문서화되어 있다.
|
||||
- [ ] [parity] desktop은 mobile에서 가능한 프로젝트 관리 기능을 모두 포함한다는 parity 기준을 정한다. 검증: mobile에서 가능한 프로젝트 관리 기능이 desktop에도 포함된다는 기준이 문서화되어 있다.
|
||||
- [ ] [iop-result-ux] IOP OpenAI API Responses-compatible 호출 결과, task 상태, 파일 변경 결과를 UX에 표시하는 기준을 정한다. 검증: IOP 실행 결과, task 상태, 파일 변경 결과가 NomadCode UX에서 어떻게 보이는지 최소 기준이 정리되어 있다.
|
||||
|
||||
## 완료 리뷰
|
||||
|
||||
|
|
|
|||
|
|
@ -6,24 +6,24 @@
|
|||
|
||||
## 목표
|
||||
|
||||
Plane 통신 토대와 provider-neutral pipeline 설계 이후, 먼저 로드맵 기반 agent-ops 운영 루프의 상태/책임 경계를 스케치에서 구체화한다. 그 다음 실제 상태 변화를 기준으로 task lifecycle, enqueue/running/completed/failed 흐름을 안정화하고 retry, timeout, notification event의 최소 구조를 추가해 core workflow의 운영 기준을 만든다.
|
||||
Plane 통신 토대와 provider-neutral pipeline 설계 이후, 로드맵 기반 agent-ops 운영 루프를 NomadCode Core와 MCP-first 외부 제어 표면이 품는 방향으로 정리한다. 그 다음 실제 상태 변화를 기준으로 task lifecycle, enqueue/running/completed/failed 흐름을 안정화하고 retry, timeout, notification event의 최소 구조를 추가해 core workflow의 운영 기준을 만든다.
|
||||
|
||||
## Milestone 흐름
|
||||
|
||||
완료된 Milestone은 archive 경로를 가리키고, 검토중, 진행중, 계획, 스케치 또는 보류 Milestone은 이 Phase 하위 `milestones/` 경로를 가리킨다.
|
||||
완료, 검토중, 진행중, 계획, 스케치 순서를 기본으로 하되, 이번 Phase에서는 `Roadmap Driven Agent-Ops Automation` 스케치가 `Workflow Core` 구현의 선행 조건이므로 스케치를 먼저 둔다.
|
||||
완료, 검토중, 진행중, 계획, 스케치 순서를 기본으로 하되, 이번 Phase에서는 `Roadmap Driven Agent-Ops Automation`이 `Workflow Core` 구현의 선행 조건이므로 먼저 둔다.
|
||||
|
||||
- [스케치] Roadmap Driven Agent-Ops Automation
|
||||
- [계획] Roadmap Driven Agent-Ops Automation
|
||||
- 경로: `agent-roadmap/phase/workflow-core/milestones/roadmap-driven-agent-ops-automation.md`
|
||||
- 요약: Workflow Core 구현 전에 사용자가 중요 판단과 상위 계획을 맡고, 에이전트가 로드맵-마일스톤-계획-리뷰 루프를 자동으로 이어가는 운영 컨셉을 구현 가능한 계획으로 구체화한다.
|
||||
- 요약: Workflow Core 구현 전에 사용자가 입력과 출력 검토를 NomadCode 라인에서 해결하고, 외부 에이전트는 MCP를 통해 roadmap/action core를 제어하는 운영 방향을 구현 가능한 계획으로 정리한다.
|
||||
|
||||
- [계획] Workflow Core
|
||||
- 경로: `agent-roadmap/phase/workflow-core/milestones/workflow-core.md`
|
||||
- 요약: Roadmap Driven Agent-Ops Automation 스케치가 `[계획]` 수준으로 구체화된 뒤 task lifecycle, 상태 전이 책임, 실패 정책, retry/timeout, notification event 모델을 안정화한다.
|
||||
- 요약: Roadmap Driven Agent-Ops Automation의 Core/MCP-first 계약을 기준으로 task lifecycle, 상태 전이 책임, 실패 정책, retry/timeout, notification event 모델을 안정화한다.
|
||||
|
||||
## Phase 경계
|
||||
|
||||
- Workflow Core는 canonical task lifecycle, retry/timeout envelope, heartbeat, terminal 상태 기록을 소유한다.
|
||||
- `Roadmap Driven Agent-Ops Automation` 스케치가 먼저 상태/책임/자동화 경계를 정리해야 `Workflow Core` 구현의 task lifecycle과 완료 이벤트 계약을 확정할 수 있다.
|
||||
- `Roadmap Driven Agent-Ops Automation`이 먼저 상태/책임/자동화 경계를 정리해야 `Workflow Core` 구현의 task lifecycle과 완료 이벤트 계약을 확정할 수 있다.
|
||||
- 외부 협업 도구 notification 발송, provider별 실제 comment/status 전송, 복잡한 workflow DSL은 후속 Phase로 넘긴다.
|
||||
- IOP/A2A/model runtime 내부 정책은 외부 실행 표면 또는 adapter 책임으로 둔다.
|
||||
|
|
|
|||
|
|
@ -7,58 +7,43 @@
|
|||
|
||||
## 목표
|
||||
|
||||
NomadCode가 로드맵을 중심으로 판단, 실행, 리뷰 루프를 끊기지 않게 운영하는 컨셉을 정리한다. 사용자는 중요 판단과 상위 계획을 결정하고, 에이전트는 그 판단을 바탕으로 마일스톤 구체화, plan 생성, 작업, code-review, 재계획, 완료 반영을 표준 루프로 이어가도록 만드는 방향을 다듬는다. 이 스케치는 Workflow Core 구현 전에 task lifecycle과 완료 이벤트 계약의 방향을 정하는 선행 작업이다.
|
||||
NomadCode가 로드맵을 중심으로 사용자 입력, 실행 상태, 출력 검토, 완료 승인까지 한 흐름에서 운영하도록 Roadmap Operations Control Plane의 방향을 정한다. NomadCode Core는 roadmap/workflow/action 상태 전이를 소유하고, 외부 에이전트는 MCP-first 제어 표면을 통해 Core를 호출하며, agent-ops 스킬은 문서 작성, 의미 해석, 변경 제안, MCP 호출 준비 계층으로 낮춘다.
|
||||
|
||||
## 상태
|
||||
|
||||
[스케치]
|
||||
http://127.0.0.1:8080/v1
|
||||
[계획]
|
||||
|
||||
## 승격 조건
|
||||
|
||||
- [ ] 로드맵, Phase, Milestone, plan, code-review, runtime 완료 이벤트 사이의 책임 경계를 정의한다.
|
||||
- [ ] 사용자가 반드시 결정해야 하는 항목과 에이전트가 표준선으로 채워도 되는 항목을 구분한다.
|
||||
- [ ] `[스케치]`, `[계획]`, `[진행중]`, `[검토중]`, `[완료]` 상태 전환 조건을 NomadCode 자동화 흐름에 맞게 검증한다.
|
||||
- [ ] `[계획]` 이상으로 승격된 후속 Milestone에서 사용할 `agent-task/m-<milestone-slug>` 생성, 반복 리뷰, `complete.log`, roadmap 갱신, archive 승인 흐름의 최소 계약을 정한다.
|
||||
- [ ] 자동 실행 범위와 중단 조건, `USER_REVIEW.md` 사용자 확인 지점, 실패 또는 보완 필요 시 되돌아가는 정책을 정한다.
|
||||
- [ ] 첫 구현 Milestone으로 쪼갤 후보와 완료 기준을 나눈다.
|
||||
- 없음
|
||||
|
||||
## 구현 잠금
|
||||
|
||||
- 상태: 잠금
|
||||
- 결정 필요:
|
||||
- [ ] 사용자가 직접 승인해야 하는 경계가 milestone 생성, plan 생성, 작업 시작, 검토중 전환, 완료 archive 중 어디까지인지 정한다.
|
||||
- [ ] NomadCode가 백그라운드에서 자동 진행해도 되는 작업 단위와 명시 확인이 필요한 작업 단위를 정한다.
|
||||
- [ ] "현재 작업" 질의가 스케치/계획/진행중 후보를 어떤 우선순위로 보여줘야 하는지 정한다.
|
||||
- 상태: 해제
|
||||
- 결정 필요: 없음
|
||||
|
||||
## 범위
|
||||
|
||||
- roadmap 중심 운영 루프의 제품 컨셉 정리
|
||||
- Workflow Core 구현 전에 필요한 상태/책임/완료 이벤트 경계 정리
|
||||
- Milestone 상태 전환과 구현 잠금의 운용 기준
|
||||
- `[계획]` 이상 Milestone에서 사용할 milestone 기반 plan/code-review 반복 루프의 자동화 후보 정의
|
||||
- 완료 이벤트가 roadmap에 반영되는 방식과 사용자 최종 확인 지점 정리
|
||||
- NomadCode 내부 agent orchestration 후보 정리
|
||||
- NomadCode Core가 품을 roadmap/action core 책임 정의
|
||||
- MCP-first 외부 agent 제어 표면 방향 정의
|
||||
- HTTP API와 MCP의 역할 분리
|
||||
- 사용자 입력, 출력 검토, 승인, 보완, archive 확인을 NomadCode 라인에서 처리하는 흐름 정의
|
||||
- agent-ops roadmap skills를 작성/제안/MCP 호출 준비 계층으로 낮추는 방향 정의
|
||||
- completion event, `USER_REVIEW.md`, 완료 리뷰, dependency lock을 Core action으로 다루는 기준 정의
|
||||
|
||||
## 필수 기능
|
||||
## 기능
|
||||
|
||||
### Epic: [roadmap-loop] Roadmap-led operation loop
|
||||
### Epic: [control-plane] Roadmap operations control plane
|
||||
|
||||
로드맵과 마일스톤을 기준으로 에이전트가 다음 작업을 판단하고, 계획/작업/리뷰/재계획을 반복하는 운영 루프를 구체화한다.
|
||||
NomadCode 내부 core logic이 roadmap 기반 작업 운영을 소유하고, 외부 agent는 MCP를 통해 제어하는 구조를 정리한다.
|
||||
|
||||
- [ ] [loop-map] 초기 컨셉에서 roadmap, milestone, plan, code-review, complete.log, archive까지 이어지는 상태 흐름을 정의한다.
|
||||
- [ ] [decision-boundary] 사용자 판단 영역과 에이전트 자동 보강 영역을 구분한다.
|
||||
- [ ] [automation-contract] 자동으로 진행 가능한 단계와 중단 또는 사용자 확인이 필요한 단계를 정한다.
|
||||
- [ ] [user-review-stop] 반복 실패와 테스트 환경 차단 상황에서 `USER_REVIEW.md`로 루프를 멈추는 조건과 템플릿 계약을 정한다.
|
||||
- [ ] [runtime-routing] `[계획]` 이상 Milestone의 task group과 완료 이벤트가 roadmap 갱신으로 이어지는 routing 계약을 정한다.
|
||||
- [ ] [first-slice] 구현 가능한 첫 Milestone 또는 Epic 후보를 분리한다.
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- [ ] 컨셉이 `[계획]` Milestone으로 승격 가능한 목표, 범위, 완료 기준을 갖춘다.
|
||||
- [ ] 사용자 결정 항목과 에이전트 표준 처리 항목이 분리된다.
|
||||
- [ ] plan/code-review 반복 루프와 roadmap 갱신 루프의 최소 계약이 문서화된다.
|
||||
- [ ] 자동 루프 중단 조건과 사용자 리뷰 파일 계약이 문서화된다.
|
||||
- [ ] 첫 구현 단위 후보가 하나 이상 도출된다.
|
||||
- [ ] [core-state] roadmap, Phase, Milestone, plan, code-review, completion event, approval 상태를 Core가 다루는 state model과 revision/idempotency 계약으로 정리한다.
|
||||
- [ ] [core-actions] validate, position, propose/apply change, transition, archive, dependency check, completion event ingest를 Core action 후보로 정의한다.
|
||||
- [ ] [mcp-tools] 외부 agent용 MCP tool 표면을 Core action wrapper로 정의하고 `dry_run`, `expected_revision`, `idempotency_key`, `actor`, `reason` 입력 원칙을 정한다.
|
||||
- [ ] [http-role] HTTP API는 Flutter UI, webhook, internal integration용 표면으로 유지하고, 외부 agent 제어는 MCP-first로 여는 기준을 정한다.
|
||||
- [ ] [review-gates] 사용자 입력, 출력 검토, `USER_REVIEW.md`, 완료 승인, archive 승인을 NomadCode workflow 안의 review gate로 처리하는 흐름을 정한다.
|
||||
- [ ] [skill-adapter] agent-ops roadmap skills가 action owner가 아니라 semantic authoring/proposal layer와 MCP call preparation layer가 되도록 축소 기준을 정한다.
|
||||
- [ ] [first-slice] 첫 구현 단위를 `roadmap.validate`, `roadmap.get_position`, `roadmap.ingest_completion_event` 중 어떤 순서로 자를지 정한다.
|
||||
|
||||
## 완료 리뷰
|
||||
|
||||
|
|
@ -72,16 +57,17 @@ http://127.0.0.1:8080/v1
|
|||
|
||||
## 범위 제외
|
||||
|
||||
- 실제 runtime scheduler 구현
|
||||
- 백그라운드 agent 실행 큐 구현
|
||||
- UI 화면/API/DB schema 확정
|
||||
- 외부 provider 또는 IOP 세부 통합
|
||||
- IOP 내부 모델 라우팅, MCP/tool policy, output validation, RAG, context compression 구현
|
||||
- 전체 Flutter UI 구현
|
||||
- Plane/Jira/Mattermost provider projection 세부 구현
|
||||
- 사용자 승인 없는 자동 archive 이동
|
||||
- agentic-framework 공통 스킬의 실제 개편
|
||||
|
||||
## 작업 컨텍스트
|
||||
|
||||
- 관련 경로: `agent-roadmap/`, `agent-ops/skills/common/plan/SKILL.md`, `agent-ops/skills/common/code-review/SKILL.md`, `agent-ops/skills/common/update-roadmap/SKILL.md`
|
||||
- 표준선(선택): 로드맵은 판단과 방향의 source of truth로 둔다. 이 `[스케치]` 자체는 구현 계획 대상이 아니며, 승격 이후 구현 작업만 milestone 기반 `agent-task/m-<milestone-slug>/` 루프로 분리한다.
|
||||
- 선행 작업: Client Integration Standardization, Work Item Provider Pipeline Design
|
||||
- 후속 작업: Workflow Core, `[계획]` 승격 후 runtime, roadmap updater, UI/agent interaction 중 첫 구현 Milestone 후보를 결정한다.
|
||||
- 확인 필요: 이 스케치를 `[계획]`으로 올릴 때 실제 구현 Milestone을 runtime, roadmap updater, UI/agent interaction 중 어디부터 나눌지 결정해야 한다.
|
||||
- 관련 경로: `services/core/internal/workflow/`, `services/core/internal/scheduler/`, `services/core/internal/http/`, `packages/contracts/`, `agent-roadmap/`, `agent-ops/skills/common/update-roadmap/SKILL.md`, `agent-ops/skills/common/plan/SKILL.md`, `agent-ops/skills/common/code-review/SKILL.md`
|
||||
- 표준선(선택): NomadCode Core는 roadmap/action 상태 전이의 source of truth이고, MCP는 Core를 외부 에이전트에게 여는 adapter다. agent-ops 스킬은 사용자의 자연어와 문서 초안을 Core/MCP 호출 입력으로 정리한다.
|
||||
- 로컬 제어 표면 후보: `http://127.0.0.1:8080/v1`
|
||||
- 선행 작업: Work Item Provider Pipeline Design, 로드맵 스킬 운영 복잡도 평가, Core/MCP-first 방향성 합의
|
||||
- 후속 작업: Workflow Core, Roadmap Operations Control Plane 첫 구현 slice, MCP tool contract 작성
|
||||
- 확인 필요: 없음
|
||||
|
|
|
|||
|
|
@ -25,26 +25,19 @@ Plane 통신 토대와 별도 pipeline 설계가 정리된 뒤 실제 상태 변
|
|||
- retry / timeout 기본 구조 추가
|
||||
- notification event 구조 정리
|
||||
- Plane 통신 토대와 후속 pipeline 설계에서 확인된 상태 변화와 실패 케이스 반영
|
||||
- Roadmap Driven Agent-Ops Automation 스케치에서 정리되는 로드맵/마일스톤/plan/review/완료 이벤트 책임 경계 반영
|
||||
- Roadmap Driven Agent-Ops Automation의 Core/MCP-first 계약에서 정리된 로드맵/마일스톤/plan/review/완료 이벤트 책임 경계 반영
|
||||
|
||||
## 필수 기능
|
||||
## 기능
|
||||
|
||||
### Epic: [workflow-core] Workflow lifecycle stability
|
||||
|
||||
Core task lifecycle과 상태 전이 책임, 실패/재시도/timeout/notification event 기준을 안정화한다.
|
||||
|
||||
- [ ] [lifecycle-model] task lifecycle 상태 모델 점검
|
||||
- [ ] [transition-ownership] scheduler와 workflow service의 상태 전이 책임 정리
|
||||
- [ ] [failure-policy] 실패 task 처리 기준
|
||||
- [ ] [retry-timeout] retry와 timeout의 최소 정책
|
||||
- [ ] [notification-model] notification event 모델과 발행 지점
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- [ ] task가 enqueue 이후 running, completed, failed 상태로 일관되게 전이된다.
|
||||
- [ ] 실패와 timeout이 관찰 가능한 상태로 남는다.
|
||||
- [ ] retry 정책의 최소 동작 방식이 구현되거나 명확히 문서화된다.
|
||||
- [ ] notification event가 workflow 상태 변화와 연결된다.
|
||||
- [ ] [lifecycle-model] task lifecycle 상태 모델 점검. 검증: task가 enqueue 이후 running, completed, failed 상태로 일관되게 전이된다.
|
||||
- [ ] [transition-ownership] scheduler와 workflow service의 상태 전이 책임 정리. 검증: 상태 전이 책임이 code/docs/tests에서 중복 없이 읽힌다.
|
||||
- [ ] [failure-policy] 실패 task 처리 기준. 검증: 실패와 timeout이 관찰 가능한 상태, metadata, error로 남는다.
|
||||
- [ ] [retry-timeout] retry와 timeout의 최소 정책. 검증: retry 정책의 최소 동작 방식이 구현되거나 명확히 문서화된다.
|
||||
- [ ] [notification-model] notification event 모델과 발행 지점. 검증: notification event가 workflow 상태 변화와 연결된다.
|
||||
|
||||
## 완료 리뷰
|
||||
|
||||
|
|
@ -67,12 +60,13 @@ Core task lifecycle과 상태 전이 책임, 실패/재시도/timeout/notificati
|
|||
|
||||
- 이전 출처: `services/core/README.md`의 `## 단계별 다음 작업`
|
||||
- 주요 작업 영역: `services/core/internal/workflow/`, `services/core/internal/scheduler/`, `services/core/internal/notification/`
|
||||
- 선행 작업: Plane Communication Foundation, Work Item Provider Pipeline Design, Roadmap Driven Agent-Ops Automation 스케치 구체화
|
||||
- 선행 조건: Roadmap Driven Agent-Ops Automation 스케치를 `[계획]` 수준으로 구체화해 task lifecycle과 완료 이벤트 계약의 방향을 확정한다.
|
||||
- 선행 작업: Plane Communication Foundation, Work Item Provider Pipeline Design, Roadmap Driven Agent-Ops Automation
|
||||
- 선행 조건: Roadmap Driven Agent-Ops Automation이 `[계획]` 상태에서 Core/MCP-first 로드맵 action 계약을 기준선으로 제공한다.
|
||||
- 후속 작업: External Integration
|
||||
- 현재 지점: Flutter-first Client Consolidation, Client Integration Standardization, Work Item Provider Pipeline Design이 완료되었고, workflow 상태 전이 구현 전에 Roadmap Driven Agent-Ops Automation 스케치 구체화가 선행되어야 한다.
|
||||
- 현재 지점: Flutter-first Client Consolidation, Client Integration Standardization, Work Item Provider Pipeline Design이 완료되었고, workflow 상태 전이는 Roadmap Driven Agent-Ops Automation의 Core/MCP-first 방향성을 반영해 진행한다.
|
||||
- 책임 경계:
|
||||
- NomadCode Workflow Core는 task lifecycle 전이, retry/timeout envelope, heartbeat, terminal 상태 기록을 소유한다.
|
||||
- Roadmap Operations Control Plane은 roadmap 상태 전환, archive, dependency lock, 완료 이벤트 반영 action을 Core 로직으로 소유하고 MCP를 외부 agent 제어 표면으로 제공한다.
|
||||
- IOP/A2A/model runtime은 외부 실행 표면이며, 내부 실행 정책과 런타임 세부 retry는 각 adapter 또는 외부 런타임 책임으로 둔다.
|
||||
- Workflow Core는 외부 호출 결과를 `completed`, `failed`, `canceled`, `waiting_for_user` 같은 canonical 상태/metadata로 정규화한다.
|
||||
- notification 최소 범위:
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
NomadCode Core는 사용자 요청을 작업 단위로 받고, 작업 상태를 저장하며, 비동기 Agent 작업 흐름을 관리하기 위한 서버입니다.
|
||||
|
||||
초기 목표는 작업 생성과 조회, PostgreSQL 기반 작업 상태 저장, River 기반 비동기 작업 실행, Plane/Mattermost Adapter stub 구성, IOP OpenAI-compatible Responses 호출 경로 확보입니다. NomadCode Core는 직접 모델 런타임, 모델 라우팅, RAG, MCP, output validation, fallback 정책을 소유하지 않고 IOP를 실행/최적화 계층으로 사용합니다.
|
||||
초기 목표는 작업 생성과 조회, PostgreSQL 기반 작업 상태 저장, River 기반 비동기 작업 실행, Plane/Mattermost Adapter stub 구성, IOP OpenAI-compatible Responses 호출 경로 확보입니다. NomadCode Core는 직접 모델 런타임, 모델 라우팅, RAG, 모델 실행용 MCP/tool policy, output validation, fallback 정책을 소유하지 않고 IOP를 실행/최적화 계층으로 사용합니다. Roadmap Operations Control Plane처럼 NomadCode 내부 상태/action을 외부 agent에게 여는 MCP 표면은 Core의 후속 제어 adapter 범위로 둡니다.
|
||||
|
||||
## 현재 구현 범위
|
||||
|
||||
|
|
@ -25,7 +25,8 @@ NomadCode Core는 사용자 요청을 작업 단위로 받고, 작업 상태를
|
|||
- IOP native protocol 연동
|
||||
- Agent Integrator 연동 또는 대체 여부 확정
|
||||
- Outline / Forgejo / Nextcloud 연동
|
||||
- MCP 서버
|
||||
- Roadmap Operations Control Plane MCP 서버
|
||||
- IOP 내부 MCP/tool policy
|
||||
- Web Agent UI
|
||||
- Flutter 앱
|
||||
- 복잡한 권한 정책
|
||||
|
|
|
|||
Loading…
Reference in a new issue