SHABLE Platform / Development Progress
개발 전용 화면입니다 — 실제 ERP/마케팅 AI 업무 화면이 아닙니다. 아래 상태는 전부 정적 스냅샷(lib/dev-progress/phases.ts)이며, 실시간 실행 상태를 흉내내지 않습니다.
전체 개발 흐름
Foundation
COMPLETED모노레포 툴링, 공유 설정 패키지, 디자인 시스템(Phase 0~1-A, 1D-UI-0)
ERP
IN PROGRESS6개 바운디드 컨텍스트 완료(Inventory/Purchasing/Sales/Customers/Orders/Accounting), HR·결산 등 잔여
AI Secretary
NOT STARTED착수 전 — 일정·메일·문서 자동화
Marketing AI
IN PROGRESSAI-1~AI-16 완료(main 병합됨). AI-17(Phase A — 자연어 업무 지시 → WorkRequest → Task) 구현 완료(feature branch, main 병합 대기). ERP UI(Phase J)는 다음 단계로 명시적으로 미룸
AI Employee Infrastructure
IN PROGRESSAgent Core·Pipeline Orchestration·Scheduler·Approval Gate·Publishing Connector·Performance Intelligence·Feedback Optimization Loop(자동 실행 포함)·Capability Management(Agent+Task 양쪽)·Natural Language Work Instruction(AI-17) 기초 완료. Organization/Manager/Delegation/채용 UI 등은 미착수
Staging Deployment
COMPLETEDAWS Lightsail(Docker Compose, Caddy 리버스 프록시)에 실제 배포 완료 — 대표자가 언제나 브라우저로 개발 진행 상황을 확인 가능. main 병합 → Deploy/scripts/deploy-staging.sh 1회 실행으로 반복 가능한 업데이트(코드 동기화 → build → migration → 무중단에 가까운 재기동 → health check → smoke test). 도메인/HTTPS 는 다음 단계로 명시적으로 미룸
Marketing AI Phase 현황
| Phase | 내용 | 상태 |
|---|---|---|
| AI-1 | Agent Core Architecture 설계 | COMPLETED |
| AI-2 | Agent Core Foundation + Persistence + Execution Plane2A(Foundation)·2B(Persistence/Control Plane API)·2C(Execution Plane/Provider·Tool) | COMPLETED |
| AI-3 | Marketing Research Agent | COMPLETED |
| AI-4 | Marketing Strategy / Keyword Strategy / Content Planning Agents | COMPLETED |
| AI-5 | Content Writer Agent | COMPLETED |
| AI-6 | Visual Intelligence + Image Generation Foundation실제 이미지 생성 Provider 미연결(벤더/비용 결정 대기) — 계획 구조까지 완료 | COMPLETED |
| AI-7 | Marketing Pipeline Orchestration Foundation | COMPLETED |
| AI-8 | Scheduler / Persistent Worker / Retry / Recovery / Idempotency | COMPLETED |
| AI-9 | Human Approval / Safety Gate | COMPLETED |
| AI-10 | Channel Content Adaptation + Publishing Connector Foundation실제 Naver 등 외부 Connector 는 미등록(공식 API 폐지) — Dry-Run Connector 만 등록 | COMPLETED |
| AI-11 | Performance Analytics + Search/Ranking Intelligence FoundationNaver Search API HUB 실제 크레덴셜 없음 — Mock Connector 로 계약 검증, 실제 검색 인증은 대기(NAVER SEARCH REAL VERIFICATION PENDING) | COMPLETED |
| AI-12 | Feedback / Optimization / Re-planning Loop1차 Closed Loop 완성(Finding→Decision→[Agent Task | ReplanningRequest] 두 경로 구조적 분리). LLM 미사용 — 결정론적 규칙 기반 | COMPLETED |
| AI-13 | Autonomous Improvement Loop ClosureWorker 가 원자적 claim 으로 PENDING ImprovementTask/ReplanningRequest 를 승인 경계 안에서 자동 실행까지 연결(사람의 link-* 수동 호출 없이). ReplanningRequest 는 원본을 수정하지 않는 새 child PipelineRun 부분 재실행으로 자동 트리거 | COMPLETED |
| AI-14 | Business Goal / Campaign FoundationAI-7 부터 선반영만 되고 미사용이던 Schedule/PipelineRun.campaignId 를 실제 실행 계층에 연결. BusinessGoal→Campaign→Schedule→WorkItem→PipelineRun 순으로 campaignId 가 실제로 전달되고 fresh-GET 으로 확인됨. KPI 숫자 필드 의도적 부재, Capability Management(AI-15)/Autonomous Goal Planner 는 범위 밖 | COMPLETED |
| AI-15 | Capability Management FoundationAgent.role 단일 문자열 전제("역할 하나=Agent 하나")를 깨는 최소 기반 — Code-declared Capability Registry + Agent.capabilities 참조 배열. role 은 그대로 유지(자동 병합, 완전히 불투명), findByCapability 신설+findByRole 하위 호환 확장. main 병합 완료 | COMPLETED |
| AI-16 | Task-level Capability Execution IntentAI-15 가 남긴 후속 조건 이행 — Task.capabilityId(생성 시점 고정, 재시도/재개에도 불변)를 신설해 "이 Task 가 어떤 capability 로 실행되는가"를 기록. ExecuteTaskUseCase 가 task.capabilityId ?? agent.role 을 기존 Python dispatch 슬롯에 그대로 실어 Python 은 0줄 변경. role=null Agent 의 조용한 provider 폴백 위험(AI-15 검증에서 발견) 해소를 실행 경로로 직접 증명. capabilityId 는 응답 전용(요청 바디에 없음) — 사람이 직접 입력하지 않는다는 UX 원칙 유지. main 병합 완료 | COMPLETED |
| AI-17 | Natural Language Work Instruction(Phase A)"AI 직원 선택 → 자연어 지시 → WorkRequest" 최초 구현. Hybrid 구조 — Python 은 LLM 1회 호출로 capability plan 만 제안(untrusted proposal), Node 가 Registry+선택 Agent 보유를 all-or-nothing 으로 재검증한 뒤에만 기존 CreateTaskUseCase/ExecuteTaskUseCase 로 Task 를 생성·실행(무수정 재사용). resolvedPlan 은 RESOLVED 전이 시점에 고정, 재시도/재개 시 LLM 재호출 없음. 기존 RunMarketingPipelineUseCase/MARKETING_CONTENT_PIPELINE 은 한 줄도 안 바뀜 — 완전히 별도 orchestration 경로. 실제 Anthropic 호출로 RESOLVED→EXECUTING→COMPLETED 전체 흐름과 hallucination 방어를 라이브 검증(아래 스냅샷). ERP UI 는 다음 Phase(J)로 명시적으로 미룸(main 병합 대기) | COMPLETED |
AI Pipeline Visualization — 실제 구축된 실행 흐름
| 단계 | 설명 | 상태 |
|---|---|---|
| 1. Business Goal / Campaign | AI-14 — 사람이 정의하는 영속적인 업무 목적. Autonomous Goal Planner 없음(사람이 Schedule/PipelineRun 에 수동 연결) | COMPLETED |
| 2. Schedule | AI-8 — 언제/얼마나 자주 실행할지, AI-14 부터 campaignId 전달 | COMPLETED |
| 3. WorkItem | AI-8 — Persistent Work Queue | COMPLETED |
| 4. Worker | AI-8 폴링 루프, AI-10 에서 PublishAttempt 소비까지 확장 | COMPLETED |
| 5. Pipeline | AI-7 — 6단계 자동 오케스트레이션 | COMPLETED |
| 6. Research | AI-3 — Marketing Research Agent | COMPLETED |
| 7. Strategy | AI-4 — Marketing/Keyword Strategy | COMPLETED |
| 8. Content | AI-4(Planning)+AI-5(Writing) | COMPLETED |
| 9. Visual Planning | AI-6 — 실제 이미지 생성은 Provider 미연결 | COMPLETED |
| 10. Channel Adaptation | AI-10 — Naver Blog 어댑터만 등록, 나머지 채널은 미등록 | COMPLETED |
| 11. Approval | AI-9(PipelineRun 단계) + AI-10(PublishAttempt 단계), 실제 6개 stage 기본 정책은 AUTO | COMPLETED |
| 12. Publishing Connector | AI-10 — Dry-Run Connector 만 등록. 실제 외부 게시 Connector 없음(§ Naver 공식 API 폐지) | COMPLETED |
| 13. Search Observation | AI-11 — Naver Search API HUB Connector 구현 완료, 실제 인증은 크레덴셜 발급 대기. Mock Connector 로 계약 검증 | COMPLETED |
| 14. Performance Analysis | AI-11 — 스냅샷 시계열 비교 기반 결정론적 Finding 생성(RISING/DECLINING). LLM 호출 없음 | COMPLETED |
| 15. Improvement Decision | AI-12 — Finding 을 결정론적 규칙에 통과시켜 다음 행동(MONITOR/CONTENT_IMPROVEMENT/KEYWORD_REPLANNING)을 판단. LLM 호출 없음 | COMPLETED |
| 16. Improvement Task / Replanning Request | AI-12 — 실행 가능한 개선은 Agent Task 로 브리지, 재계획 필요는 ReplanningRequest 로 별도 기록. 두 경로는 코드 구조상 명확히 분리(공유는 상태 어휘뿐) | COMPLETED |
| 17. Autonomous Worker Claim | AI-13 — Worker 가 원자적 claim(PublishAttempt 와 동일 계약)으로 PENDING 항목만 가져가 실제 Agent Task 생성/부분 PipelineRun 재실행까지 자동 연결. WAITING_APPROVAL 은 claim 대상에서 원천 배제(승인 경계는 DB 쿼리 자체가 강제) | COMPLETED |
AI-10 진행 체크리스트
| 항목 | 상태 |
|---|---|
| Canonical Content Model | COMPLETED |
| Channel Adapter 구조 | COMPLETED |
| Naver Blog Adapter | COMPLETED |
| Publishing Connector 추상화 | COMPLETED |
| Dry Run Connector | COMPLETED |
| Approval Gate 연동 | COMPLETED |
| Publish Idempotency | COMPLETED |
| Retry / Failure 분류 | COMPLETED |
| Audit / Lineage | COMPLETED |
| 테스트(단위+Prisma 통합+e2e) | COMPLETED |
AI-11 진행 체크리스트
| 항목 | 상태 |
|---|---|
| Search Observation Model(provider-neutral) | COMPLETED |
| Provenance Model(OFFICIAL/OBSERVED/USER_PROVIDED/DERIVED/INFERRED) | COMPLETED |
| Naver Search API HUB Connector | COMPLETED |
| Naver Search 실제 인증 검증 | BLOCKED |
| Mock Search Connector(계약 검증용) | COMPLETED |
| Search Tracking Target(§18 시뮬레이션 게시 등록 차단) | COMPLETED |
| Performance Snapshot(시계열 최소 persistence) | COMPLETED |
| 결정론적 추세 분석(Rising/Stable/Declining) | COMPLETED |
| Finding Model(Evidence-first) | COMPLETED |
| Idempotency(관찰·스냅샷·Finding 전부) | COMPLETED |
| 테스트(단위+Prisma 통합+e2e) | COMPLETED |
AI-12 진행 체크리스트
| 항목 | 상태 |
|---|---|
| ImprovementDecision 모델(결정론적, LLM 미사용) | COMPLETED |
| Finding → Decision 규칙(HIGH 하락→재계획/LOW·MEDIUM 하락→개선/개선→모니터) | COMPLETED |
| 두 경로 구조적 분리(classifyDecisionArtifact — Agent Task ↔ ReplanningRequest) | COMPLETED |
| ImprovementTask ↔ 기존 Agent Core Task 브리지(신규 Task 시스템 미생성) | COMPLETED |
| ReplanningRequest ↔ PipelineRun lineage(AI-12 시점엔 사람의 수동 link-pipeline-run 만 지원 — AI-13 에서 자동 부분 재실행으로 확장됨) | COMPLETED |
| 승인 경계(requiresApproval, 이중 결정 방지) | COMPLETED |
| Idempotency(findingId/decisionId unique) | COMPLETED |
| Provenance/Evidence lineage 유지(Finding→Snapshot 추적 보존) | COMPLETED |
| 테스트(단위+Prisma 통합+e2e) | COMPLETED |
AI-13 진행 체크리스트
| 항목 | 상태 |
|---|---|
| ImprovementTask/ReplanningRequest 원자적 claim(CLAIMED 상태, PublishAttempt 와 동일 compare-and-set) | COMPLETED |
| claim 2단계 저장(linkedAgentTaskId/linkedPipelineRunId 선기록 → LINKED 확정, crash recovery 최소 경계) | COMPLETED |
| 진짜 부분 재실행(sourceRunId+startAtStage, 원본 PipelineRun 절대 불변, parentRunId lineage) | COMPLETED |
| 원본 pipelineRunId 생성 시점 캡처(ImprovementDecision.originPipelineRunId, Worker 시점 추론 없음) | COMPLETED |
| 승인 경계 유지(WAITING_APPROVAL/REJECTED/DISMISSED/LINKED 는 claim 대상 아님) | COMPLETED |
| Worker claim → execute → persist 패턴 재사용(AI-8/AI-9/AI-10과 동일, Scheduler 재설계 없음) | COMPLETED |
| 동시 Worker claim 경쟁 테스트(실제 SQLite 파일, Promise.all 동시 호출) | COMPLETED |
| Closed-loop e2e(사람의 link-* 수동 호출 없이 Worker tick 만으로 LINKED 까지 도달) | COMPLETED |
| 테스트(단위+Prisma 통합+e2e) | COMPLETED |
AI-14 진행 체크리스트
| 항목 | 상태 |
|---|---|
| BusinessGoal/Campaign 최소 모델(KPI 숫자 필드 의도적 부재, DRAFT→ACTIVE→PAUSED→COMPLETED+CANCELLED) | COMPLETED |
| Campaign→BusinessGoal 관계 존재 검증(문자열 저장이 아니라 실제 조회로 확인, 없으면 404) | COMPLETED |
| Schedule.campaignId 실제 검증·연결(생성 시 존재 확인, WorkItem 으로 전파) | COMPLETED |
| WorkItem.campaignId 신설(Schedule→WorkItem 전파용 최상위 필드, JSON payload 와 분리) | COMPLETED |
| PipelineRun.campaignId 실제 연결(Worker 경로 + 수동 POST /v1/pipeline-runs 경로 양쪽 모두 존재 검증) | COMPLETED |
| AI-13 lineage 무변경 확인(originPipelineRunId/parentRunId/claim 메커니즘 전부 회귀 테스트 통과) | COMPLETED |
| ImprovementDecision/ReplanningRequest — campaignId 컬럼 중복 추가하지 않음(원본 PipelineRun 조회로 파생 가능, ADR-0033) | COMPLETED |
| Capability Management(Agent.role)/Autonomous Goal Planner 범위 밖 유지 | COMPLETED |
| 테스트(도메인+애플리케이션+Prisma 통합+e2e, 실제 시나리오 e2e 포함) | COMPLETED |
AI-15 진행 체크리스트
| 항목 | 상태 |
|---|---|
| Code-declared Capability Registry(현재 실사용 6개 id 만 등록) | COMPLETED |
| Agent.capabilities 참조 배열 + Registry 검증(unknown/중복 거부) | COMPLETED |
| role → capabilities 자동 병합(role 은 여전히 완전히 불투명) | COMPLETED |
| migration/backfill 실제 DB fresh query 검증(dev.db 18개 Agent) | COMPLETED |
| findByCapability 신설(ACTIVE only, createdAt+id deterministic) | COMPLETED |
| findByRole 하위 호환 확장(role 또는 capabilities 매치, 삭제 없음) | COMPLETED |
| Improvement/Replanning closed loop 전환(findByRole→findByCapability 2줄만) | COMPLETED |
| Marketing Pipeline 명시적 배선 경로 유지 + role 검증 capability-aware 확장 | COMPLETED |
| Task-level capability ambiguity — 의도적 미해결(ADR 후속 조건 명시, capabilities[0] fallback 없음) | NOT STARTED |
| 테스트(도메인+애플리케이션+Prisma 통합+e2e, 기존 AI-1~14 무변경 회귀) | COMPLETED |
AI-16 진행 체크리스트
| 항목 | 상태 |
|---|---|
| Task.capabilityId 신설(create() 팩토리로만 설정, setter 없음) | COMPLETED |
| 도메인+영속화 이중 immutability(Prisma upsert 의 update 절에서 의도적 제외) | COMPLETED |
| CreateTaskUseCase — Registry 존재 + Agent 실보유 검증(AgentCapabilityMismatchError 신설) | COMPLETED |
| ExecuteTaskUseCase — effectiveExecutionIntent 로 Python 0줄 변경 실행 의도 전달 | COMPLETED |
| role=null Agent 의 조용한 provider 폴백 위험(AI-15 발견) 실행 경로 레벨 해소 증명 | COMPLETED |
| RunMarketingPipelineUseCase/LinkImprovementTaskToAgentTaskUseCase 연결(AI-13 계약 무변경) | COMPLETED |
| Migration — 백필 없음(NULL 이 이미 정확한 legacy 값) | COMPLETED |
| capabilityId 는 응답 전용, 요청 바디 미노출(사람이 직접 입력하지 않는다는 UX 원칙) | COMPLETED |
| Natural Language Planner/Organization/Manager/Delegation/Platform Intelligence 미래 원칙 문서화(ADR-0036, 구현 없음) | COMPLETED |
| 테스트(도메인+애플리케이션+Prisma 통합, 기존 AI-1~15 무변경 회귀) | COMPLETED |
AI-17 진행 체크리스트(Master Roadmap Phase A)
| 항목 | 상태 |
|---|---|
| WorkRequest 애그리거트 신설(PENDING→RESOLVED|REJECTED→EXECUTING→COMPLETED|FAILED) | COMPLETED |
| Python Planner — LLM 1회 호출, 상태 없음, ExecutionRequest(Task 전용) 재사용하지 않음 | COMPLETED |
| LLM 결과는 untrusted proposal — Python 스키마 닫힌 목록 + Node 독립 재검증 2중 방어 | COMPLETED |
| Registry 존재 검증(isKnownCapabilityId) + 선택 Agent 실보유 검증 all-or-nothing | COMPLETED |
| 검증 실패(hallucination 포함) 시 Task 0건 생성, WorkRequest 전체 REJECTED | COMPLETED |
| CreateTaskUseCase/ExecuteTaskUseCase 무수정 재사용(capabilityId 그대로 연결) | COMPLETED |
| retry/resume — resolvedPlan 고정, taskIds 기준 재개(LLM 재호출 없음, QUEUED Task 마저 실행) | COMPLETED |
| 기존 RunMarketingPipelineUseCase/MARKETING_CONTENT_PIPELINE 무수정(완전히 별도 경로) | COMPLETED |
| capabilityId 는 요청 바디에 없음(응답 전용) — 사람이 직접 입력하지 않는다는 UX 원칙 유지 | COMPLETED |
| ERP AI Employee UX(Phase J)는 이번 범위 밖 — 의도적으로 미착수 | NOT STARTED |
| 테스트(도메인+애플리케이션+Prisma 통합+e2e, 기존 AI-1~16 무변경 회귀) + 실제 Anthropic 라이브 검증 | COMPLETED |
마지막 실제 검증 기록(정적 스냅샷)
Dry-Run 게시 검증
DRY RUN — 실제 게시 아님실제 Anthropic 6단계 파이프라인 → canonical content 조립 → Naver Blog 어댑터 변환 → Worker 자동 폴링이 dry-run 게시까지 완전 자동 수행(사람 개입 없음). 실제 외부 게시 아님.
- PipelineRun ID
- a751ee64-4f32-4b58-83a2-03628a31afe1
- 채널
- NAVER_BLOG
- Connector
- dry-run
- 게시 모드
- DRY_RUN
- 실행 상태
- PUBLISHED
- externalPostId(시뮬레이션 값)
- dryrun-df870228-a1f7-4080-888a-59c1b0b992be
Search Observation 검증
MOCK — 실제 Naver 응답 아님Mock Connector 로 정규화·idempotency 계약 실제 검증. 기존 AI-10 Dry-Run PublishAttempt 로 검색 추적 대상 등록을 시도해 422(SimulatedPublishNotTrackableError)로 실제 거부됨을 확인(§18). 실제 Naver Search API HUB 크레덴셜은 아직 없음 — NAVER SEARCH REAL VERIFICATION PENDING.
- Connector
- mock-search
- 쿼리
- ai-marketing-automation
- 수집된 관찰 수
- 3
- §18 시뮬레이션 게시 배제
- 실제 확인됨
- 실제 Naver 크레덴셜 상태
- PENDING
Improvement Decision Loop 검증
결정론적 규칙 — LLM 미사용HIGH 심각도 하락 Finding → decide → ReplanningRequest 생성 → 승인 → 사람이 수동 생성한 기존 PipelineRun id 를 link-pipeline-run 으로 사후 기록(새 PipelineRun 자동 트리거 없음). LOW/MEDIUM 하락은 CONTENT_IMPROVEMENT → ImprovementTask → 승인 → link-agent-task 로 실제 Agent Core Task 생성까지 별도로 확인. 전부 e2e 로 실제 HTTP 호출 검증, LLM 호출 없음.
- Finding 유형 / 심각도
- SEARCH_VISIBILITY_DECLINE / HIGH
- Decision 종류
- KEYWORD_REPLANNING
- 경로(§ 두 경로 구조적 분리)
- REPLANNING_REQUEST
- 최종 상태
- LINKED
Autonomous Improvement Loop Closure 검증
사람의 link-* 수동 호출 0회CONTENT_IMPROVEMENT 경로 — 승인 직후 Worker tick 1회만으로 실제 Agent Core Task 생성까지 자동 연결(사람의 link-agent-task 호출 0회) 확인. KEYWORD_REPLANNING 경로 — 승인 직후 Worker tick 1회만으로 원본 PipelineRun 은 그대로 둔 채 parentRunId 로 연결된 새 child PipelineRun 을 자동 생성해 KEYWORD_STRATEGY 단계부터 COMPLETED 까지 실행(사람의 link-pipeline-run 호출 0회) 확인. WAITING_APPROVAL 항목은 tick 을 3회 반복해도 전혀 움직이지 않음을 별도로 확인. 전부 e2e 로 실제 HTTP 호출 검증.
- 검증 경로
- REPLANNING_REQUEST
- LINKED 까지 걸린 Worker tick 수
- 1
- 사람이 호출한 link-* 횟수
- 0
- WAITING_APPROVAL 무시된 tick 수(승인 경계)
- 3
Business Goal / Campaign lineage 검증
campaignId 실제 연결(단순 컬럼 아님)BusinessGoal 생성 → 그 아래 Campaign 생성 → Campaign 에 연결된 ONE_TIME Schedule 생성 → Worker tick 으로 실제 실행 → WorkItem/PipelineRun 양쪽 모두 fresh GET 으로 campaignId 확인. POST /v1/pipeline-runs 직접 호출 경로도 별도로 검증. 존재하지 않는 campaignId/businessGoalId 로 생성 시도는 전부 404 로 거부됨을 확인. 전부 e2e 로 실제 HTTP 호출 검증.
- BusinessGoal
- SHABLE 온라인 검색/콘텐츠 마케팅 성장
- Campaign
- 네이버 검색 유입 확대
- Schedule.campaignId 영속화
- 실제 확인됨
- PipelineRun.campaignId 영속화
- 실제 확인됨
Natural Language Work Instruction 검증(AI-17)
실제 Anthropic 호출실제 Node(:4003)+Python(:8003) 두 서버, 실제 Anthropic 호출로 POST /v1/work-requests(해석) → POST .../execute(실행) 전체 흐름 검증. 두 번째 시도는 LLM 이 우연히 호환되는 필드명을 사용해 실제 ResearchReport 까지 완주(COMPLETED). 별도로 Registry 밖 capability(hallucination)를 강제 반환하도록 만든 시나리오는 e2e 테스트로 REJECTED + Task 0건 생성을 확인.
- 업무 지시(자연어)
- My objective is to find AI automation marketing angles. The product or service is a small-business ERP platform. Please research this.
- 내부적으로 판단된 capability
- MARKETING_RESEARCHER
- WorkRequest 최종 상태
- COMPLETED
- Task 최종 상태
- COMPLETED
발견된 한계(정직하게 기록, 다음 개선 후보)
재검증(2026-09-18) 결과, 이전 표현("가끔 필드명을 잘못 추측한다")은 실제 문제를 과소평가했다 — 정정: 현재 등록된 6개 capability 중 MARKETING_RESEARCHER(objective/productOrService, 단순 문자열)를 제외한 5개(MARKETING_STRATEGIST/KEYWORD_STRATEGIST/CONTENT_PLANNER/CONTENT_WRITER/VISUAL_PLANNER)는 이전 Task 가 만든 완전히 검증된 typed 객체(ResearchReport/MarketingStrategy/KeywordStrategy/ContentItem/GeneratedContent)를 그대로 입력으로 요구한다(6개 Python Pydantic 스키마 전수 조사로 확인, 추정 아님) — 자연어 지시만으로는 원천적으로 구성할 수 없는 형태라 "가끔 틀림"이 아니라 "이 경로로는 항상 불가능"하다. Phase A 는 한 step 의 output 을 다음 step 의 input 으로 연결하는 inter-step typed data flow 를 의도적으로 구현하지 않았다(설계 문서 §4, 범위 밖으로 명시). 따라서 AI-17 이 실제로 완성한 것은 "자연어 지시 → capability 선택 → WorkRequest/Task 생성 → 안전한 orchestration" 기반이며, MARKETING_RESEARCHER 외 다른 capability 를 포함하는 multi-step 자율 워크플로우 전체가 완성된 것으로 간주해서는 안 된다. 해소 방향은 MASTER-ROADMAP.md 의 "Capability Contract & Inter-Step Data Flow Foundation"(다음 우선 Phase 로 명시) 참고.