feat(workflow): email 프리셋 + 요청 체인 (채널 에이전트 토대) - #55
Conversation
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
채널 에이전트 구상(비전 §4(d))의 Workflow측 토대: email-triage/ email-reply 표시 프리셋, 요청 생성 시 parentRequestId 연결(실존 검증, 미존재 404), 체인 전체 조회 API(조상 추적+자손 포함, createdAt 오름차순), REQUEST_CREATED 이력에 체인 필드, DecisionSheet에 이전 요청 표시. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5fcfa09de4
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| console.log(`📨 결정 요청 수신: [${request.actorId}] (${request.subjectType}) ${request.subject.title}`); | ||
| broadcast({ type: 'WORKFLOW_REQUEST_CREATED', item: request }); | ||
| recordHistory({ event: 'REQUEST_CREATED', requestId: request.requestId, actorId: request.actorId, subjectType: request.subjectType, title: request.subject.title }); | ||
| recordHistory({ event: 'REQUEST_CREATED', requestId: request.requestId, actorId: request.actorId, subjectType: request.subjectType, title: request.subject.title, parentRequestId: request.parentRequestId }); |
There was a problem hiding this comment.
Persist parentRequestId in history entries
When a chained request is created, this call appears to add parentRequestId to the audit trail, but appendHistory() rebuilds entries from a fixed whitelist and does not copy input.parentRequestId, so /api/history and persisted history still lose the chain link. In any email/request-chain flow that relies on history for auditability, the created event cannot be tied back to its parent unless the history entry schema is updated to store this field.
Useful? React with 👍 / 👎.
요약
PR #54에서 문서화한 채널 에이전트 구상의 Workflow측 토대 2건 구현.
스펙:
docs/superpowers/specs/2026-08-04-workflow-email-presets-chain-design.mdemail-reply(↩ 수신자 + 제목/초안),email-triage(✉ 발신자 + 처리방침) — 기존 spend/publish 패턴, 서버는 유형을 모름.parentRequestId(선택) — 실존 부모 검증(미존재 404 PARENT_REQUEST_NOT_FOUND).GET /api/decision-requests/:id/chain(운영자 토큰)이 조상 추적+자손 포함 체인을 createdAt 오름차순으로 반환 — "메일 스레드 = 결정 체인"의 토대.테스트
체인 3건(A→B→C 중간 노드 조회, 404, 엄격 모드 401) + 프리셋 4건 + 시트 1건 신규 — 전체 서버 26 + UI 29 통과. record-only 원칙·기존 계약 무변경.
경계
workflow/+ docs만 수정.🤖 Generated with Claude Code