Repository navigation
architecture: validate the agent delivery journey and native interaction recipes #314
Description
Interaction review — 2026-10-23
P1 · 已有指导方向正确;需要用真实产品的失败场景验证手册和脚手架。
Observed evidence and scope
agent-native.md already assigns product interaction meaning to products and mechanisms/evidence to Rivet. Consumer inspection now provides concrete cases: Payback save/draft lifetime, Autarx/Threadly selection-bound asynchronous details, and RegexMate keyboard result inspection. These belong in the clean-room journey validation before proposing new shared UI abstractions.
Source snapshot: 1ced9e9e898173d9b95a9fdd0e746ef822b6c51a. Central policy read: d32f8400264c3b6dddd613d207331934e2d7694e; Rivet interaction guide read at 1ced9e9e898173d9b95a9fdd0e746ef822b6c51a.
Product decision
- Validate taskboard, then one actual product, with a narrow task brief, interaction table and native acceptance.
- Use two consumer proofs before extracting a reusable mechanism/recipe. Product form policy, brands, layouts and paywalls remain outside Rivet.
- Keep stable diagnostics/discovery and existing CI; no claim that RPC or screenshot success alone proves interaction parity.
Acceptance before closing
- A fresh agent can implement/review one keyboard/focus/draft/error-recovery scenario using documented inputs only.
- Required native legs report source/pins/artifact and persisted effects. Missing OS evidence stays pending; no new selector language or theme engine is introduced.
Handoff boundary
This is an architect review and implementation contract, not a runtime fix. Refresh the repository, relevant open PRs and current policies before taking one bounded slice; record starting SHA, owned files and native evidence. Preserve active writers and existing release/security gates. A paused product is not automatically restarted. Source findings and required failure-injection scenarios above are not claimed as three-platform runtime validation. Use synthetic data; do not access real keys, publish content or operate real hardware for this review.
Shared baseline: product experience contract.
Earlier issue context (retained)
Policy discovery follow-through (2026-10-23)
The default-branch AGENTS now directly links the family delivery, documentation-language and portfolio policies (638539577d489765c0ed454eb48777421413ad48). Each bounded slice must refresh/read these inputs and record the repository and policy revision actually read. The 25 audited repositories now expose these inputs from their default-branch AGENTS. Link coverage is not proof that a running agent has acknowledged them. Existing mobile/desktop implementation ownership stays in the current handoff; the clean-room newcomer journey and native interaction evidence below remain required.
审查结论(P1,2026-10-23)
现有 inspect/doctor/schema/acceptance/matrix 已覆盖开发主线,不需要再造编排层。跨宿主交互规则应在产品契约中;Rivet 提供机制和可验证的脚手架。现有 #310(pin 误报)、#311(无消费者 Kotlin 生成)、#312(设备网关后续)优先沿原 issue 处理。
实施顺序与范围
先完成 #310/#311 的可复现诊断修正;再用 taskboard 从干净安装开始演练一个不看源代码的用户简报→脚手架→交互契约→打包验收闭环。记录失败时稳定原因码与下一步,列出必须由人判断的产品/安全边界。第二个真实产品重复后才上收通用 recipe 或最小 scaffold 改进。不要借此引入 UI DSL、跨平台 selector、主题引擎或支付依赖。
这是产品/架构路线入口。每次仅认领一个可验收切片,开工记录 starting SHA、owned files、命令与回滚;活动共享层切片完成后再进入,不重叠写入,不重写已有实现。
完成标准
干净目录、固定依赖与 source SHA 能复现;开发模式和已打包应用证据分别记录;三桌面要求未跑不算成功;交互场景验证焦点、草稿、取消/恢复而非只有 RPC 输出;设备 companion 不标成独立移动产品交付。
固定审查证据
本轮是源码、文档、主页与公开发布资产的静态审查,未声称已经运行所有原生平台、硬件或真实支付。执行时重新核对当前状态。
沿用的工作
- doctor --release: env-mediated pins read as empty refs, historical changelog refs compared against the installed release #310
- Kotlin client is generated for every project, so the freshness gate fails on trees that ignore .rivet/ #311
- follow-ups from the RVT1 device gateway review (#305) #312
家族规范入口
产品交付标准、完整审查与主页规划 PR。依赖图仍以 Keel family architecture 为准。具体实现与证据留在本仓已有 canonical 文档;不要另建平行规范。
Activity
turinglambdaai commentedon Oct 25, 2026
进度更新(2026-10-25,macOS 腿会话)
按本 issue 的实施顺序,前置诊断修正已全部落地:
${{ env.RIVET_PIN }}等)按同文件 env 块解析,无法解析的仍 fail safe;tag 形态的 pin 只对配置文件比对已安装版本,changelog 历史不再误判。.rivet/的树不再失败。下一个可验收切片(按本 issue 定义,未开工)
干净目录的 taskboard 闭环演练:fresh agent 仅凭文档输入完成一个 keyboard/focus/draft/error-recovery 场景的简报→脚手架→交互契约→打包验收,记录 starting SHA、owned files、命令与回滚。macOS 腿可先行,三桌面证据未齐前本 issue 不关;不引入 UI DSL、跨平台 selector、主题引擎。
当前 main:03b3a35 之后(含 #322 DMG 背景修复,PR #323 已合并)。
turinglambdaai commentedon Oct 25, 2026
切片完成:taskboard 干净房闭环演练(macOS 腿,2026-10-25)
执行方式:按本 issue 验收标准「A fresh agent can implement/review one scenario using documented inputs only」——由一个无上下文的 fresh agent(无 rivet 内部知识)仅凭 docs/、生成的项目 AGENTS.md、参考驱动 macos-ax.swift 和 CLI help 完成实现与验收;产品 owner 只提供用户简报,验收官独立重跑复核。
结果
raco rivet acceptance --jsonexit=0(验收官独立重跑确认可复现)schema-contract:schema 基线兼容门禁add-task-contract:4 组 RackUnit——空标题不动 State/存储、真实 JSON 持久化、fresh-namespace 重启模拟、手写 LE 编解码的真 RVT1 回环(Hello/Record 线上形状/$state 事件/Error 帧)macos-add-task-ui:打包产物上 AX 驱动真实键入 + Return + Esc 全交互断言 → 有序关窗 → 同数据根重启校验持久化~/Codes/taskboard-journey/。Fresh-agent 判定(对验收标准第一条)
主体足够,四处必须自由发挥(详见演练日志第 3 节 G1–G10):Record 值 Racket 侧语义(
record-ref靠黑盒枚举发现)、Optional null =(void)、backend 测试路径(serve进程内驱动零指南)、native-ui 启动编排与键盘注入(macOS 侧全自行设计)。这些知识只落在了演练项目的代码注释里,未回流上游——已立独立 issue 跟进。本切片不声称
三桌面 parity(仅 macOS 腿)、第二个产品重复、无新抽象引入(无 UI DSL/selector/主题引擎)。
下一切片(按本 issue 顺序)
turinglambdaai commentedon Oct 25, 2026
切片完成:文档修复复验演练(2026-10-25 晚)
按本 issue 切片顺序「补齐 G1–G5 → 重复演练验证」执行完毕:
五项判定(对照第一轮演练的「必须自由发挥」)
record-ref结论:docs 修复有效。fresh agent 从「四处越线」收敛到「一处局部 + 若干小缺口」。
剩余缺口(复验新录,均已记录在 #325 讨论)
进程内配方的 fresh-namespace 细节、
rivet/protocol完整名面、零参 RPC 语法、Error 帧 payload 编码二义、数据目录指南(第一轮 G7,仍未文档化)等中小缺口——见 #325 的复验评论。本切片不声称
三桌面 parity、第二个真实产品重复。下一切片:#325 中小缺口收尾(数据目录指南优先)→ 第二个产品演练 → recipe 上收讨论。
turinglambdaai commentedon Oct 26, 2026
切片完成:第二真实产品演练 · RegexMate 键盘结果检视(2026-10-25 深夜)
本 issue 实施顺序的「真实产品」第一步完成(review 腿)。执行方式同前:无上下文 fresh agent + 仅文档输入 + 产品简报;验收官复核(工作区零残留、CI 全绿、PR 已合并)。
交付(regexmate PR #7,已合并,main @ 3f0b558)
[a-错误态(内联错误 + 草稿保留)→ 恢复。证据 9 项(4 AX 快照含错误态 + 4 按窗截图 + trace 31 actions/22 assertions)。本机 acceptance 5/5、run-tests 81/81、CI 三平台 8/8。新发现的真实桌面缺口(rivet 侧,已立独立 issue)
并行会话事故处置记录
演练中撞上另一会话的 pin bump 切走了分支——agent 按跨设备纪律把 commit 迁回短命分支、main 复位 origin、未 push main,全程记录在 journey-log。教训:同机多会话并行同一仓库必须 git worktree 隔离(AGENTS 已有此规,实际执行又验证了一次)。
#314 剩余路径
真实产品证明 #1(RegexMate)✅ → 真实产品证明 #2(Payback save/draft 生命周期)已启动(后台演练中) → 齐后进入 recipe 上收讨论(哪些机制值得上游化:key-view loop 修复模式?契约表模板?e2e 驱动骨架?)。
turinglambdaai commentedon Oct 26, 2026
结案:agent 交付旅程验证完成(两个消费者证明齐备,2026-10-26)
本 issue 的实施顺序已全部执行完毕,按其自身完成标准结案(「Missing OS evidence stays pending」条款如实适用)。
执行轨迹(全部有合并交付或 issue 承接)
Recipe 上收候选(两个产品证明了同一边界,上收门槛已满足)
以下模式在两个真实产品上重复出现,值得写进 rivet 的参考驱动与文档(#328/#329 的实现载体):
如实声明(pending 项)
fresh agent 亲笔的交互场景腿在 macOS 完成;Linux/Windows 的 native-ui 验收格由两产品各自的既有套件在 CI 三平台矩阵证明(全绿)。演练产物(4 份 journey-log)在原机器本地
~/Codes/*-journey/,未入库。状态
入口 issue 的排序使命完成;残留工作全部有独立 issue 承接(#328、#329、payback#30)。关闭本 issue。