Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[Feature] Preserve minimal provenance on durable task evidence

Abierto
  • ¿Algo no está bien?
#35 3 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@hachemchaabi ya está trabajando en esto.

Desde el 23/9/2026.

  • #43 de @hachemchaabi — abierto

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
typescript
Área
backend, backend-api-design

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
5.2k
Forks
730
Merge medio
3 d 20 h
PR fusionados (30 d)
96

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de CopilotKit/openmuse

Todos los issues de CopilotKit/openmuse

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.