발견한 문제: POST /conversations/:id/messages가 sender_mode=twin을
검증 없이 그대로 저장·브로드캐스트하고 있었음 -- 에스컬레이션 게이트는
초안 생성(/draft) 경로에만 있었고 실제 발송 경로엔 없어서, 클라이언트가
/draft를 거치지 않고 바로 twin 메시지를 보내면 안전선을 완전히
우회할 수 있었다.
- ai-service: /draft와 별개인 POST /escalate/check 하드게이트 엔드포인트 추가
- core-backend: AIServiceClient.checkEscalation 추가, 메시지 저장 직전에
twin 발송이면 무조건 호출하도록 해서 발송이 실제로 일어나는 단
하나의 지점에서 막음. AI 서비스 응답 불가 시 fail-safe로 발송 차단.
에스컬레이션되면 저장/브로드캐스트 없이 escalation_logs에만 기록.
사람이 직접 보내는 메시지는 게이트 대상 아님
- core-backend: DELETE /users/:id 추가 -- 유저가 걸린 모든 행(트윈 설정·
화이트리스트·연락처·대화참여·메시지·에스컬레이션로그·유저 본인)을
트랜잭션으로 삭제 (tech-design.md §5 "사용자가 언제든 초기화 가능")
- 온디바이스 암호화·데이터 흐름 대시보드는 Flutter 클라이언트 책임이라
이 환경에서는 보류, roadmap.md에 근거 남김
ai-service/ wraps generate_draft/escalation_filter/retrieve_style
behind a single POST /draft endpoint that the Go core will call
internally. poc/tone-corpus/ stays untouched for corpus experiments
and blind-eval; this is the promoted copy meant for the real service.
Verified with TestClient: style_examples path, history/retrieval
path (confirms the earlier scoring fix still ranks the on-topic
exemplar first), escalation short-circuit, and 422 validation when
zero or both of style_examples/history are given.
Still missing: the Go core's actual HTTP client calling this service.
2.3 (Flutter) needs a Flutter/Dart SDK this environment doesn't
have, so it can't be built or verified here the way core-backend
and the AI pipeline can. Swapping it with 2.2 (Python AI service)
keeps work unblocked instead of writing unverifiable Flutter code;
2.3 moves to wherever the user has the Flutter SDK installed.
Ports the Python prototype (backend/) to the actual chosen stack --
Gin + gorilla/websocket + GORM, same DB schema (models.go mirrors
backend/app/models.py), same endpoints (signup, message send,
WebSocket relay). backend/ stays as a reference prototype, not
removed.
Verified with go test: signup, duplicate-invite-code rejection (409),
404 on an unknown conversation, and WebSocket broadcast delivery all
pass -- the same cases the Python version was checked against.
Push notifications, AI service integration, and multi-device sync
are not in this commit -- see core-backend/README.md.
The build order already ended with the PoC-gated section, but it
wasn't stated as a hard rule. Now roadmap.md and AGENTS.md both say
not to touch Phase 1 §3 until items 1-5 of the build order are fully
finished, even if PoC data happens to land earlier -- no jumping the
queue to fill in a value early.
Reconsidered pure Go (would mean reimplementing and re-verifying the
already-tested AI pipeline) and pure Python (leaves perceived
performance/concurrency headroom on the table for a preemptive
scale bet). Landed on: Go handles auth/messaging/DB, Python keeps
owning generate_draft/escalation_filter/retrieve_style behind an
internal API. backend/ (Python) is now labeled a verified prototype
for the Go rewrite to match, not the final service.
Native wasn't actually required for the v2 OS-layer notification
listener -- Flutter reaches it via platform channels like any other
native Android API, same pattern many production apps already use.
Flutter's faster iteration on the chat UI (already validated in the
click prototype) matters more for v1 than starting native. Updates
tech-design.md §8, roadmap.md's checklist, and AGENTS.md accordingly.
FastAPI app with invite-code signup, message send/relay over
WebSocket, and the DB schema from roadmap.md Phase 1 §2.1 (users,
contacts, conversations, messages, twin_settings, whitelist_rules,
escalation_logs). Defaults to SQLite for local dev, PostgreSQL in
prod per tech-design.md §8.
Verified end-to-end with TestClient: signup, duplicate-invite-code
rejection (409), message persistence, 404 on an unknown conversation,
and WebSocket broadcast delivery all behave as expected.
Push notifications and the AI pipeline integration (item 3) are not
in this commit -- see backend/README.md and roadmap.md's checklist.
tech-design.md §8 settles the stack (Android/Kotlin, Python/FastAPI,
PostgreSQL, WebSocket relay, Room+SQLCipher) so it stops blocking
item 1 of the build order. roadmap.md's Phase 1 breakdown is now
checkboxes instead of prose, and AGENTS.md adds the rule to check/
update that checklist before and after any Phase 1 app-build task,
rather than tracking progress ad hoc.
PoC execution is on hold for now, so this splits Phase 1 into work
that's independent of PoC results (backend infra, client shell, AI
pipeline productionization) vs. values that genuinely need PoC data
(autonomy defaults, whitelist topics, trust UX copy) -- so
infrastructure work isn't blocked while PoC recruiting catches up.
Update PLANNING.md §2 from empty checkboxes to the working answers in
decision-log, fix the reverse OS/self-app wording, and clarify roadmap
Phase 3 so OS-layer growth does not rewrite the start order.
Co-authored-by: okuma <o0kuma@users.noreply.github.com>
Resolves the open Q1-Q7 questions as tentative decisions (self-app beta
first, target consumers, MVP scenario = read-receipt relief + group-chat
catch-up, autonomy capped at L0-L2) and builds the standard deliverable
set on top of them, ready for review at the next meeting.
Claude
Cursor Agent