Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

[Feature] Preserve minimal provenance on durable task evidence

未关闭
  • 哪里不对？
#35 3 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

@hachemchaabi 已经在做这个了。

开始于 2026年9月23日。

  • #43 来自 @hachemchaabi —— 未关闭

评估

难度
5/5
预计耗时
一周以上
新手友好度
35/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
typescript
领域
backend, backend-api-design

调研方向

Start by tracing the current Evidence shape and the named producers: delegated read_web, recurring monitors, search results from #22, and browser identity from #29. Define a minimal optional provenance envelope that preserves direct observations, provider excerpts, sessions, monitors, and observation times while keeping existing mail/file/user records and UI rendering compatible; verify the restart, shared-session, monitor, provider-change, and backward-compatibility cases listed in the issue.

由索引模型根据 Issue 内容生成。

描述

What outcome should OpenMuse handle?

Durable task evidence should retain enough provenance to tell what was actually observed, where it came from, and how it was acquired.

Today Evidence is intentionally small:

{
  id,
  kind: "mail" | "file" | "web" | "user",
  title,
  excerpt,
  url?
}

That works while each kind has one obvious source, but the current repo is already crossing that boundary:

  • delegated read_web persists a direct browser observation as kind: "web";
  • recurring monitors persist their page observation as kind: "web";
  • #22 persists search-provider excerpts as kind: "web";
  • #29 separates browser observation identity from browser-session identity, but the evidence record still does not retain that acquisition provenance.

Those records can have the same URL/excerpt shape while meaning different things. A search excerpt is provider-returned evidence about a page; a browser read is an OpenMuse observation of the page itself. Treating both as the same provenance makes later verification, stale-data handling, debugging, and Learning/export harder.

The invariant I think we need is:

evidence content is not its provenance.

Proposed behavior

Add the smallest provenance envelope that is useful across existing evidence producers, without turning Evidence into a generic knowledge graph.

For example, optional fields along the lines of:

  • observedAt
  • source / acquisition such as browser, monitor, search, mail, user
  • a stable source/entity reference when one exists (messageId, browser session, monitor, provider, etc.)

The exact schema is less important than preserving these distinctions:

  • observation identity vs source/container identity;
  • direct observation vs provider-supplied excerpt;
  • source data vs authority.

I would keep provider-specific payloads out of the core record. Search-provider names or query IDs can live in a small optional provenance object if needed, while the main evidence shape stays stable.

How would we verify it works?
  • A direct browser read and a search result for the same URL remain distinguishable after task restart.
  • Two observations from one persistent browser session have distinct evidence IDs but share the correct source/session provenance.
  • Monitor evidence identifies the monitor and observation time without using the monitor ID as the observation ID.
  • Search adapters can change providers without changing the core evidence schema.
  • Existing mail/file/user evidence remains backwards-compatible.
  • UI can continue rendering title/excerpt/url without knowing provider details.

This seems worth deciding while #22/#28 add search and before more connectors or Automatic Learning depend on the current evidence shape.

AI-use note: I used an AI assistant to trace the current evidence producers and draft this issue; I verified the cited browser, monitor, mail, UI, and #22 search paths against current source/PR heads before filing.

主要语言
TypeScript
星标
5.2k
派生
730
平均合并
3 天 20 小时
30 天内合并 PR
96

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

CopilotKit/openmuse 的其他 Issue

查看 CopilotKit/openmuse 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。