[Epic] O1: prove one durable digital employee across mem, doc, and runtime

[PeterGuy326]

schemaVersion: requirement-record.v1
revision: R2
status: ready
priority: P0
productOwner: "@PeterGuy326"
technicalOwner: "unassigned"
userOutcome: "A prospective builder can observe one named digital employee — the support answerer — work durably across the mem, doc, and digital-employee planes: a durable support case resumed across sessions and channels, answers cited from approved document revisions, reviewable knowledge updates, and independent export of package, memory, and documents."
requirements:
  - REQ-001
  - REQ-002
  - REQ-003
  - REQ-004
  - REQ-005
acceptanceCriteria:
  - AC-001
  - AC-002
  - AC-003
  - AC-004
  - AC-005
  - AC-006
  - AC-007
parent: "https://github.com/bytefolk/.github/issues/6"
dependencies:
  - "https://github.com/bytefolk/digital-employee/issues/6"
  - "https://github.com/bytefolk/mem/issues/68"
  - "https://github.com/bytefolk/doc/issues/2"
supersedes:
  - "R1 unnumbered epic draft with unnamed proof scenario"
lastDecisionAt: "2026-08-23T06:08:42Z"

Context

Demonstrate one reliable digital employee across the three product planes with durable context, revision-stable document evidence, human-reviewed changes, and independent portability. This epic is the executable counterpart of the organization vision RFC.

On 2026-08-23 the product owner kicked off this proof and named the first scenario (DEC-GH-7-002): a support answerer — a pre-sales/customer-support answering employee.

Named proof scenario: the support answerer

The support answerer stands in for its owner in front of customers:

1. It answers customer questions from an explicitly allowlisted doc knowledge base — approved revisions only, with exact citations.
2. It resumes one in-progress support case from mem across two sessions/channel adapters, keeping durable context and source locators.
3. It turns a requested knowledge update (for example an FAQ correction) into a doc proposal that a human reviews and commits — never a silent mutation.
4. Its employee package, memory workspace, and document bundle export independently.

Why this scenario: it is the smallest employee that genuinely faces an external customer, it exercises all three planes read-first and then through one reviewable write path, and it is the first concrete instance of the organization end-state — each person's agent working on their behalf in front of customers.

Requirements

REQ-001 — One named employee, three planes

Prove exactly one named employee (the support answerer) across the three product planes; breadth beyond this employee is out of scope for O1.

REQ-002 — Runtime and policy track (digital-employee)

Complete the runtime tracks listed below so the support answerer binds as an ordinary employee package.

REQ-003 — Memory and context track (mem)

Complete the memory tracks listed below so the support case is durable, correctable, and certifiable for digital-employee integration.

REQ-004 — Collaborative artifacts track (doc)

Complete the document tracks listed below so the knowledge base is revision-stable, revocable, audited, and reviewable for agent-proposed changes.

REQ-005 — Cross-plane proof execution and evidence

Run the shared acceptance scenario end to end and record completion evidence per the checklist below.

Acceptance Criteria

AC-001 — Credential-free base demo

Run the base Console support-answerer demo without DingTalk, DWS, model, mem, or doc credentials.

AC-002 — Durable case resume

Enable optional local integrations and resume one approved support case from mem across two sessions/channel adapters.

AC-003 — Cited answer from an approved revision

Answer a customer question from an explicitly allowlisted doc revision and retain exact revision/evidence locators.

AC-004 — Isolation and denial

Prove cross-principal/workspace isolation and revoked-document denial.

AC-005 — Reviewable knowledge update

Create a document-change proposal without mutating the document; after the reviewable-action phase, approve and commit it idempotently with an audit trail.

AC-006 — Independent portability

Export the employee bundle, memory workspace, and document bundle independently.

AC-007 — Evidence record

All completion-evidence items below are satisfied and pinned in one dated evidence record.

Repository tracks

Runtime and policy — digital-employee

• Runtime roadmap epic
• employee-profile.v1
• Registries and loaders
• Scoped mem backend
• Versioned doc source
• North-star integration harness

Memory and context — mem

• Trustworthy memory-loop epic
• Versioned index generations
• Immutable correction/supersede
• Digital-employee integration certification

Collaborative artifacts — doc

• Document-plane roadmap epic
• Active-room revocation and recovery
• Active-room-aware mutation/restore API
• Audit trail
• Portable document bundle
• Agent proposal/review/commit

Later trust gates

• Write-tool approval contract
• employee-bundle.v1

These later gates are tracked now so early contracts do not block a future ecosystem, but they are not prerequisites for the first read-only demonstration.

Shared acceptance scenario (instantiated for the support answerer)

Using synthetic data and pinned component/profile versions:

1. Run the base Console support-answerer demo without DingTalk, DWS, model, mem, or doc credentials.
2. Enable optional local integrations and resume one approved support case from mem across two sessions/channel adapters.
3. Answer a customer question from an explicitly allowlisted doc revision and retain exact revision/evidence locators.
4. Prove cross-principal/workspace isolation and revoked-document denial.
5. Create a knowledge-base change proposal without mutating the document.
6. After the reviewable-action phase, approve and commit it idempotently with an audit trail.
7. Export the employee bundle, memory workspace, and document bundle independently.

Completion evidence

• One documented local harness or reproducible runbook covers the scenario.
• Observable tests cover happy path, denial, revocation, stale version, unavailable dependency, and retry/idempotency where applicable.
• No credential, personal identifier, chat export, internal URL, private screenshot, or generated private index is committed.
• Each repository's required check command passes at its integration commit.
• A dated evidence record pins versions and distinguishes implemented, experimental, and planned behavior.

Non-goals (explicitly deferred)

• Hosted multi-tenancy, billing, rentals, marketplace ranking, and hardware orchestration.
• Automatic memory capture from private chats.
• External write-capable connectors before approval and audit contracts pass their own acceptance criteria.

Decisions

• DEC-[Epic] O1: prove one durable digital employee across mem, doc, and runtime #7-001 (2026-08-23T06:08:42Z): requirement record formalized to requirement-record.v1 with numbered REQ/AC, owners, and ledger; R1 tracks, scenario steps, completion evidence, and deferred scope preserved unchanged.
• DEC-[Epic] O1: prove one durable digital employee across mem, doc, and runtime #7-002 (2026-08-23T06:08:42Z): the first proof scenario is named as the support answerer (pre-sales/customer-support answering employee); approved by @PeterGuy326 on 2026-08-23 at O1 kickoff. Milestone "O1 — Cross-repository north-star proof" proposed due 2026-09-27.

Status and evidence

• Status: ready; Priority: P0
• Direction owner: product; technicalOwner: unassigned
• Baseline: R1 repository tracks as listed; plane epics in progress (digital-employee v0.4.0+, mem R1/R2, doc D0)
• Latest accepted implementation ledger: none

Change history

Revision	Effective time	Decision	Superseding comment
R1	2026-08-01	Initial unnumbered epic with unnamed proof scenario	Initial body
R2	2026-08-23T06:08:42Z	Formalize requirement-record.v1 and name the support-answerer proof scenario	Decision comment (this revision)

[PeterGuy326]

P9 需求治理 — org#7 进度同步 2026-08-07

已完成 ✅

仓库	项目	状态
digital-employee	#6 runtime epic	CLOSED (superseded by #25 North Star)
digital-employee	#7 employee-profile.v1	CLOSED
digital-employee	#8 registries/loaders	CLOSED
digital-employee	#9 scoped mem backend	CLOSED
digital-employee	#10 versioned doc source	CLOSED
digital-employee	#11 north-star integration	CLOSED (superseded by #42)
mem	#70 DE integration cert	CLOSED
doc	#3 active-room revocation	CLOSED

进行中 🟡

仓库	项目	状态
digital-employee	#42 real e2e	Phase A ✅, Phase B blocked (#12)
mem	#68 trustworthy memory loop	#55 in-progress, #69 ready
mem	#55 versioned index	in-progress
doc	#4 mutation API	ready
doc	#5 audit trail	ready

待启动 ⬜

仓库	项目	阻塞
mem	#69 correction/supersede	无 (ready)
doc	#8 portable bundle	无 (ready)
doc	#9 proposal workflow	← doc#4 + doc#5
digital-employee	#12 write approval	← M1 (#29+#27+#35)
digital-employee	#14 archive lifecycle	← #39

关键路径到 org#7 完成

doc#4 + doc#5 → doc#9 ─────┐
digital-employee #29+#27 → #35 → #12 ─┤→ #42 Phase B → org#7 共享验收场景
mem#55 + #69 ──────────────┘
doc#8 → #42 Phase C (portability)

共享验收场景 step 1-4 (read-only) 已由 #42 Phase A 覆盖。Step 5-6 (reviewed write) 待 Phase B。

[PeterGuy326]

schemaVersion: requirement-decision.v1
canonicalIssue: "https://github.com/fullstack-ai-infra/.github/issues/7"
previousRevision: R1
resultingRevision: R2
decisionType: additive
oldDecision: "R1 unnumbered epic draft; proof scenario unnamed"
newDecision: "R2 formalizes requirement-record.v1 (REQ-001..REQ-005, AC-001..AC-007) and names the first proof scenario: the support answerer (pre-sales/customer-support answering employee)"
reason: "Product owner kicked off the O1 north-star proof on 2026-08-23 and selected the support/answering scenario: it is the smallest employee that genuinely faces an external customer, exercises mem, doc, and digital-employee read-first plus one reviewable write path, and instantiates the org end-state of an agent working on its owner's behalf."
impact: "Adds a named scenario and numbered REQ/AC; repository tracks, shared scenario steps, completion evidence, and deferred scope are unchanged; milestone O1 proposed due 2026-09-27."
approver: "@PeterGuy326"
decidedAt: "2026-08-23T06:08:42Z"

[PeterGuy326]

schemaVersion: requirement-decision.v1
canonicalIssue: https://github.com/bytefolk/.github/issues/7
previousRevision: R2
resultingRevision: R3
decisionType: roadmap-reconciliation-and-execution-order
decidedAt: 2026-09-05T06:45:29Z

R3 当前有效路径

O1 仍是跨仓库的第一个真实产品证明：一个数字员工在本地 Workspace 中被创建、获得显式能力/权限、执行真实任务，并留下可检查的结果、记忆和证据。它不是员工市场发布，也不是客户端安装包发布。

竞品 OpenAgents / TabTin 只作为产品形态参照。旧的子 Issue 链路保留为历史证据；下面这条是当前执行顺序：

1. 一期闭环与验收：先按已有 D0–D4 口径补齐真实运行、回归和证据，不把市场化内容塞入一期。
2. Runtime 基线：digital-employee#253 → 重新验收 #241，digital-employee#165 (S1)；先保证引擎探测、真实 turn、失败可解释和证据链稳定。
3. Client / Workbench：digital-employee#248 作为 Launcher + Workspace 主 Epic；承接 org-workbench#155/#156/#170/#194/#196，再按 org-workbench#110 的 Launcher lanes 推进。
4. Conversation / Thread：承接 org-workbench#142/#145 的现有基线，org-workbench#143 只补可信的 Workspace Thread Context，不另造一套 session store。
5. Memory：mem#109 → mem#112；mem#151 → digital-employee#245；把持久记忆、provenance 和运行上下文接到同一条可验证链路。
6. Artifact / Citation：先完成 doc#28 的验收并补齐 doc-source integration record，再推进 org-workbench#36 的 Artifact/Knowledge/Citation 统一模型。
7. O1 验收：跨仓库真实跑通“创建 → 授权 → 执行 → 结果 → 记忆/引用 → 证据”。
8. O1 之后：再进入 MCP/Network/Skills/Connector、团队协作和员工市场化；员工市场另行定义 EmployeePackage、发布/依赖声明、托管隔离、Eval、credit 与结算契约。

当前先不调整 Issue 标签、状态或关闭历史锚点；此评论作为 R3 路线裁决，旧链接不再自动视为当前前置依赖。