[Product Slice] Turn portfolio context into an evidence-backed daily intelligence workflow

[helsome]

Problem

Folio already has portfolio/watchlist concepts, market/research tools, background-job work, notifications, and research/evidence infrastructure. However, these capabilities are not yet organized around a recurring user job that makes the product useful every day.

A financial research workbench should not require the user to repeatedly ask “research company X.” A more valuable workflow is:

“What changed today across the companies I own or watch, why does it matter, and what evidence supports that conclusion?”

Without this vertical slice, Portfolio Context (#37), Background Jobs (#38), filings/news retrieval (#32), evidence/citation, and thesis-impact logic can remain technically complete but product-level disconnected.

Related: #13 #20 #32 #37 #38 #96 #100 #102

Current state

Folio already has or is developing:

• explicit/versioned watchlist and portfolio context;
• canonical instrument resolution;
• market/news/research capabilities;
• primary-source filing/announcement retrieval;
• Deep Research and thesis-impact flows;
• scheduled/background jobs and desktop notifications;
• evidence/citation/provenance infrastructure.

There is also a known scheduler correctness issue (#96) around duplicate daily execution, which must be respected before expanding scheduled workflows.

What is missing is one product contract that connects these pieces into a safe, auditable portfolio intelligence loop.

Expected direction

Build a narrow daily/triggered intelligence workflow:

Selected Portfolio / Watchlist snapshot
  ↓
Detect meaningful new information
  ├─ filing / announcement
  ├─ material company news
  └─ relevant market/financial change
  ↓
Retrieve primary evidence
  ↓
Assess relevance / impact to the selected holdings or thesis
  ↓
Produce concise evidence-backed digest
  ↓
Persist run + context snapshot + evidence
  ↓
Notify user
  ↓
Open directly into the corresponding report/run

The workflow should distinguish new meaningful change from ordinary noise. It does not need a sophisticated ML ranking model initially; deterministic rules plus existing Agent/research judgment are acceptable if the evidence path remains inspectable.

Each result should make clear:

• which portfolio/watchlist snapshot was used;
• which company/instrument triggered the item;
• what changed;
• why it may matter to the portfolio/thesis;
• what primary/secondary evidence supports it;
• when the source/data was retrieved;
• whether the conclusion is supported or only tentative.

Safety / reliability requirements

• No automatic trading or order placement.
• Background execution must not gain additional tool permissions compared with foreground research.
• Fix or account for [Automation] Scheduled rules can run more than once on the same day #96 before claiming recurring-job correctness; one scheduled occurrence must not produce duplicate research runs/notifications.
• Portfolio/watchlist content follows the existing privacy/redaction policy and must not be emitted wholesale into unrelated telemetry.
• If no meaningful change exists, the workflow may produce a compact “no material update” result rather than fabricating activity.

Non-goals

• No full portfolio management system.
• No tax/P&L accounting engine.
• No real-time tick-by-tick alert platform.
• No automatic trade execution.
• No requirement to support every exchange/source in the first slice.
• Do not create a second background scheduler; reuse/harden the existing job infrastructure.

Validation / acceptance criteria

• Create a real watchlist or portfolio with at least 5 canonical instruments and persist a versioned snapshot.
• Run one actual portfolio-intelligence job through the production path using real retrieval/data sources.
• At least one test scenario detects a real filing/announcement/news/data change relevant to one of the selected instruments.
• The produced digest links each material item to stable evidence/source identities; factual claims are not backed only by free-text model output.
• The result records the exact portfolio/watchlist snapshot/version used, and later portfolio edits do not rewrite the historical run context.
• The user can open at least one digest item and inspect the underlying evidence/provenance.
• A scheduled occurrence executes at most once across overlapping scheduler ticks and application restart/reconciliation semantics; [Automation] Scheduled rules can run more than once on the same day #96 must be fixed or explicitly depended on before this criterion is marked complete.
• Completion/failure produces a privacy-safe notification that opens the corresponding persisted run/report.
• Include one “no material change” case and verify the system does not manufacture a meaningful event.
• Provide a reproducible test report with exact commands, Bun/OS, provider/model/source information and focused integration results.
• Because this is a visible workflow, attach screenshots of the generated digest and the evidence/report opened from its notification or entry point.

Maintainer note

This Issue is intentionally product-oriented. Prefer connecting existing portfolio, research, evidence and scheduling components over introducing another general-purpose agent subsystem.

[RXQ6]

/claim

我来接手这个 Issue。

按 CONTRIBUTING 里「大 Issue 可以拆成多个可独立合入的小 PR」的约定，我打算把它拆成可独立合入的几段推进，不一次性交付全部 acceptance criteria：

第 1 阶段（可离线验证）：给定一个版本化的 portfolio / watchlist 快照，走通「变更检测 → 证据检索 → 相关性与影响评估 → 生成 digest → 持久化 run + 快照 + 证据」这条链（fixture / 现有数据源即可），并固化断言：每个 material item 绑定稳定的 evidence / source 身份、factual claim 不只靠自由文本模型输出；run 记录使用过的快照版本且后续组合改动不回写历史；无实质变化时产出「no material update」而不是编造事件。

第 2 阶段（调度与通知）：这块我会先看 #96（重复日执行）的结论再动 —— 本 Issue 自己也写明「#96 must be fixed or explicitly depended on before this criterion is marked complete」。不新增第二套调度器，复用并加固现有 job 设施。

第 3 阶段：接真实来源跑一次，补 test report 与截图。

如果维护者希望调整切入顺序或 scope 边界，请直接指出，我按结论调整。

[github-actions]

@RXQ6 已认领该 Issue，并已自动设为 Assignee。提交 PR 时请在描述中写 Closes #103。

[RXQ6]

我在认领时说明过会分阶段推进，这里根据最新在飞的 PR 做一次 scope 收敛。

不新增第二套组合 / 调度设施。 #96 已由 PR #97 处理，#37 / #38 由 PR #56 覆盖 —— 版本化上下文、后台任务、调度去重这三块我都不会重复实现。

直接复用现有组件：

本 Issue 需要的子能力	复用谁
版本化 watchlist / portfolio 上下文、冻结快照	#37 / PR #56
持久化周期任务 + 通知深链	#38 / PR #56
同一天只执行一次（调度去重）	#96 / PR #97
变更检测与实质性判定	现有 research-diff/materiality
material item → 稳定 evidence 身份	#100 / PR #105

本 Issue 我负责的 scope 收敛为：

把已有的组合上下文、变更检测、证据检索、通知与 Deep Research 串成一个真实可运行的组合情报回路，并交付本 Issue 要求的可复现 test report 与截图，重点覆盖：

• 每个 material item 绑定稳定的 evidence / source 身份，factual claim 不只靠自由文本模型输出
• run 记录所用快照版本，后续组合改动不回写历史上下文
• 一个 "no material update" 场景，验证系统不会编造事件

调度正确性这条验收标准： 本 Issue 原文写的是 #96 must be fixed or explicitly depended on。我按"显式依赖"处理 —— 在 PR #97 合入后补齐该项验证，在此之前该项标记为 pending，不自行实现调度去重。

前置未就绪期间不阻塞等待： 先准备可复现的验收脚本（scripts/ 下，纯新增），等前置合并后填入真实运行结果。

如果维护者希望调整切入顺序，或认为某一部分已有归属应当让出，请直接指出。

[RXQ6]

/release

[github-actions]

该 Issue 已释放，可以重新认领。

[jiangjiang248]

/claim

我来处理 #103 中一个可独立合入的小范围：research-diff/materiality 在价格或置信度的前后值缺失时，不能把空值转成 0 并误判为 material change。会补聚焦回归测试和可复现测试报告。

这只是 #103 的“no material update”可靠性子能力，不会在 PR 中写 Closes #103，也不宣称完成整个产品流程。其他子能力仍可并行推进。

[github-actions]

@jiangjiang248 已认领该 Issue，并已自动设为 Assignee。提交 PR 时请在描述中写 Closes #103。

[jiangjiang248]

/release