Skip to content

Epic: E1 — Context Threading & Synthesis #1000

Description

@seonghobae

User-story epic from the planning spec (#974 §5). Stories detailed in the doc.


Roadmap item — CWL Project #1 (naruon Platform Roadmap). Phase P0 · Component naruon. Spec: #974 (docs/planning/naruon-platform-plan.md).

Active E1 slice

Agent: Codex / Started: 2026-09-26T23:47:33+09:00
Scope: Story 1.5 self-sent personal-storage classification and its source-linked knowledge/reply behavior. The epic remains open for Stories 1.1, 1.2, and 1.4 and other #1350 slices.

Activity

  1. seonghobae commented on Aug 19, 2026

    @seonghobae
    ContributorAuthor

    P0 backlog reconciliation — 2026-08-19

    E1 therefore remains open for Stories 1.1, 1.2, 1.4, and 1.5 plus the remaining #1350 slices; do not close this epic from the completion of #984 alone.

  2. added
    area: apiAPI, protocol, event, or external contract
    status: triagedOpen issue has an organization taxonomy assignment
    type: featureNew or expanded product capability
    on Aug 22, 2026
  3. seonghobae commented on Sep 26, 2026

    @seonghobae
    ContributorAuthor

    E1 story 1.5 implementation checkpoint (current #1784 head eeaf2f41): #1784 fixes the sender/recipient decision and reply-SLA path, including visible To/Cc/Bcc and configured mailbox aliases. It does not complete the personal-reference requirement.

    Current source evidence:

    • File import creates content_nodes/content_segments from email bodies in backend/services/email_import_service.py::_append_email_content_graph; live IMAP/POP3 ingestion in backend/services/imap_worker.py::process_fetched_email stores an Email and optional TicketTask without those graph records.
    • ContentNodeRecord has an email FK and node_kind, but no personal-domain field. Email.organization_id is non-null; changing it to NULL as a shortcut would break current owner-scoped search.
    • backend/api/data.py::_email_scope_filter lets organization admins query organization mail without a per-user filter. A personal_reference node label alone would therefore not establish personal-by-default access.

    Next E1 slice must create source-linked searchable reference nodes on live ingestion and carry an explicit personal domain through every read/search path that can currently use organization-wide scope. Keep #1000 open until those access checks, the import path, and the user-visible reference behavior are verified.

  4. seonghobae commented on Sep 26, 2026

    @seonghobae
    ContributorAuthor

    E1 Story 1.5 후속 작업: #1785를 #1784 위에 쌓은 Draft PR로 열었습니다. 검증된 자기 발송 메일을 개인 자료로 표시하고, IMAP/POP3 및 파일 가져오기의 본문·첨부를 기존 내용 그래프에 연결하며, 조직 관리자 데이터/프로젝트 그래프 조회에서 다른 사용자의 개인 자료를 제외합니다. 두 프로젝트 그래프 API 접근 테스트는 격리 PostgreSQL 스키마에서 통과했습니다.

    #1784의 현재 head 필수 검사가 아직 대기 중이므로 두 PR 모두 병합 완료로 보지 않습니다. #1784가 병합되면 #1785를 develop로 옮겨 현재 head 검사를 다시 확인하겠습니다. UC-08의 검색 결과 표현과 하이브리드 검색 품질은 별도로 계속 검증합니다.

  5. seonghobae commented on Sep 26, 2026

    @seonghobae
    ContributorAuthor

    Codex · 2026-09-27: Story 1.2 email-thread judgment card is in progress in #1787, stacked on #1786. The current head links owner-scoped evidence, tasks, and typed project-graph objects. External issue/code references, semantic support checks, and full-history synthesis remain open. The existing Story 1.5 work continues independently.

  6. seonghobae commented on Sep 26, 2026

    @seonghobae
    ContributorAuthor

    E1 Story 1.4 implementation evidence (Codex, 2026-09-27): docs/planning/naruon-platform-plan.md specifies event-to-event enables / conflicts / unrelated relations with evidence, confidence, and one-gesture correction. The named email_thread_edges table is not a live integration point: backend/alembic/versions/0011_email_model_reconciliation.py explicitly dropped that abandoned development-only table; current email threads use email_records and threading_service. project_graph_edges contains cited, confidence-scored object-to-object relations, but its object vocabulary does not include events and its correction path only edits objects. Story 1.4 therefore still needs an owner-scoped event relation contract, grounded extraction, and a correction path. I am taking this distinct slice; #1787 remains the separate Story 1.2 judgment-card PR and #1784/#1785 own Story 1.5.

  7. seonghobae commented on Sep 26, 2026

    @seonghobae
    ContributorAuthor

    Story 1.4 진행: Draft PR #1788을 #1785 위에 열었습니다. 현재 head cac0b6e9는 검증된 메일/ICS 원본에서 시간 지정 VEVENT를 소유자 범위의 출처 인용 이벤트로 저장합니다. 격리 PostgreSQL 저장/삭제 및 관련 파서·이관 테스트를 확인했습니다. 이벤트 간 enables/conflicts/unrelated 판단, 보정 API·화면, 독립 캘린더·숙박 출처는 아직 구현 중이며 이 PR을 Story 1.4 완료나 병합 근거로 간주하지 않습니다.

  8. seonghobae commented on Sep 27, 2026

    @seonghobae
    ContributorAuthor

    Story 1.3 is still open on protected develop@042b0c70531b229af3acbd0421a2f23098d848b3.

    • fix(search): find unparsed attachments by filename #1792 adds filename search fallback for parse failures; it is an unmerged PR.
    • feat(email): show attachment evidence in message threads #1793 adds parsed attachment segments under their parent message in the email thread; it is an unmerged PR.
    • The remaining cited-fact requirement is not covered by those slices. On the current develop path, PROJECT_GRAPH_EXTRACTION_ENABLED defaults to false, and the deterministic project extractor only emits project-object types. A parsed attachment sentence such as an invoice amount/party/commitment therefore has no generic cited fact node. The source segment and attachment link are persisted, so the evidence is available for a follow-up extractor.

    Keep the epic open for Story 1.3 until exact-segment facts are persisted and verified on protected develop, along with the pending PR gates.

  9. seonghobae commented on Sep 27, 2026

    @seonghobae
    ContributorAuthor

    Story 1.3 후속 백엔드 범위: #1795가 파싱된 첨부 문서의 명시적 날짜·금액·당사자·약속을 원문 세그먼트 인용과 첨부 연결이 있는 그래프 객체로 저장합니다. 실제 파서 출력·소유자 범위·PostgreSQL 저장을 검증했습니다. 아직 리뷰/호스팅 검사가 대기 중이며, 일반 표현의 사실 추론과 전용 사실 조회 UI는 남아 있습니다. 전체 백엔드의 기존 PostgreSQL 스모크 실패 2건은 #1794에서 수정 중입니다.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: apiAPI, protocol, event, or external contractenhancementNew feature or requestpriority: mediumNormal-priority or P2 workstatus: triagedOpen issue has an organization taxonomy assignmenttype: featureNew or expanded product capability

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions