docs: preserve established README voice
This commit is contained in:
NI0317
@@ -2,5 +2,5 @@
|
||||
# side as of the last confirmed-consistent state. Both languages carry equal authority;
|
||||
# after editing either side, bring the other along and re-record with:
|
||||
# pnpm run verify-translation-pairing --write .agents/notes/implemented/process/2026-07-22-product-first-root-readme.md
|
||||
2026-07-22-product-first-root-readme.md: bed7d3b49c58a59fa0f6d6637c9852b9fb615b63
|
||||
2026-07-22-product-first-root-readme.zh.md: fbfb726b2c1a821b323de2fbf419dc97920a6878
|
||||
2026-07-22-product-first-root-readme.md: eeef25702b9d1ce87353d620e52ae661455d9b99
|
||||
2026-07-22-product-first-root-readme.zh.md: c4026484132772e3783492aaa0e368027ae15574
|
||||
|
||||
@@ -6,30 +6,28 @@ English | [中文](2026-07-22-product-first-root-readme.zh.md)
|
||||
|
||||
## Problem
|
||||
|
||||
The root README is the repository's product front door, but a product-only coding-agent description hides the SDK and current runtime breadth, while an SDK-first package inventory delays the shortest path to a working agent. Commands, capability claims, and entry-point descriptions also drift when the README is treated as general marketing instead of a maintained product contract.
|
||||
The root README is the repository's product front door. Its product-first structure and established voice remain useful, but concrete entry points and capability claims drift as the runtime grows. Rewriting sections whose facts remain correct increases the review surface and discards language that already works.
|
||||
|
||||
## Decision
|
||||
|
||||
The root README defines DeepSeek Harness as a plugin-native coding-agent runtime that ships both a composable SDK and the assembled `dsh` agent. It separates mission from shipped facts and leads with the supported one-line installer.
|
||||
The root README preserves its existing structure, order, and wording wherever the underlying fact remains correct. A refresh changes only stale claims and adds material needed to represent shipped surfaces; it does not use repository growth as a reason to reframe the whole page.
|
||||
|
||||
A note before the installer thanks early users, states plainly that the internal preview remains unfinished, has a low overall level of completion, and falls below the experience the team wants to deliver. It invites direct reports of failures, confusion, and friction, assigning those shortcomings to the product rather than the user, while the adjacent pre-release warning keeps the compatibility boundary explicit.
|
||||
A note before installation thanks internal testers, states that features and experience remain unfinished, and asks for direct reports of failures, confusion, and friction through the WeCom group. The technical pre-release statement remains in its existing development position.
|
||||
|
||||
The README names the TUI, Web, headless, ACP, and Python/JSON-RPC entry points with commands or owning links. It summarizes capabilities by coding, orchestration, and operational families, while stating that each composition selects its own plugins. Exhaustive package and service inventories stay in the generated graphs and package-group documentation.
|
||||
The user-surface section adds the ACP automation server and Python/JSON-RPC SDK beside the existing Web, TUI, and headless entries. The capability paragraph keeps its compact inventory style while adding the shipped PTY, LSP, web, goal, planning, task, sandbox, approval, session-query, and telemetry families and stating that compositions select subsets. One adjacent bullet records the authoritative-session-log rule because persistence, replay, queries, telemetry, and interfaces depend on it.
|
||||
|
||||
Plugin-native is the organizing principle rather than a slogan: the README ties replaceable services and typed events to composition through `cordis.yml`, and ties model-visible behavior, persistence, replay, queries, telemetry, and UI projections to the authoritative session log. Detailed contracts remain with the architecture, CLI, examples, cookbook, and generated catalogs.
|
||||
|
||||
The English and Chinese README sides share the same technical structure. Their community sections point to the primary channel for each language audience. The documentation website keeps its separate user-guide landing page; the repository README is not added to that projection.
|
||||
Detailed package and service inventories remain at their owning documentation. The English and Chinese README sides share the same technical structure, while their community sections continue to point to the primary channel for each language audience. The documentation website keeps its separate user-guide landing page.
|
||||
|
||||
## Alternatives considered
|
||||
|
||||
**Present only the assembled coding agent.** This gives the shortest product pitch but makes the SDK, alternate front doors, and replaceable runtime seams look incidental even though they are shipped repository surfaces.
|
||||
**Rewrite the README around a new product narrative.** A complete rewrite can make every current surface prominent, but it replaces accurate, reviewed copy and creates unnecessary churn. Current facts fit the established product-first structure.
|
||||
|
||||
**Present the repository as an SDK and package catalog.** This exposes implementation breadth immediately but makes a new reader reconstruct the product from package names. The package map and generated capability graph remain the authoritative inventories.
|
||||
|
||||
**Use a long marketing page with screenshots, badges, and duplicated tutorials.** Rich media can demonstrate a stable product journey, but it ages separately from commands and source contracts. The root stays compact and links to runnable examples and owned guides.
|
||||
|
||||
**Project the root README as the documentation website home page.** A single landing page avoids two narratives, but the website's user guide and the repository's developer/product front door have different navigation and maintenance needs. They remain separate sources linked to the same architecture and guides.
|
||||
**Project the root README as the documentation website home page.** A single landing page avoids two narratives, but the website's user guide and the repository's product/developer front door have different navigation and maintenance needs.
|
||||
|
||||
## Consequences
|
||||
|
||||
A new reader can install or choose a runtime surface before learning the package topology, while an SDK reader can see the extension model without a generated catalog being copied into prose. The README must change with any affected command, entry point, pre-release boundary, or high-level capability family, and each claim remains reviewable against source or an owning document.
|
||||
Reviewers can distinguish factual refreshes from editorial rewrites, and future updates retain established wording unless its meaning becomes false or incomplete. The README must still change with affected commands, entry points, pre-release boundaries, or high-level capability families, while exhaustive detail remains linked rather than copied.
|
||||
|
||||
@@ -6,30 +6,28 @@ Status: implemented
|
||||
|
||||
## 问题
|
||||
|
||||
根 README 是仓库的产品入口，但仅以产品视角描述 coding agent（编程智能体）会掩盖 SDK 与当前运行时的广度，而以 SDK 为先的包（package）清单则会把启动可运行 agent 的最短路径放到后面。如果把 README 当作通用营销文案，而非持续维护的产品契约，命令、能力声明和入口描述也会逐渐漂移。
|
||||
根 README 是仓库的产品入口。其产品优先的结构和既有语气仍然有效，但随着运行时不断扩展，具体入口和能力声明会逐渐陈旧。重写事实仍然正确的章节，会扩大评审范围，也会丢弃已经行之有效的措辞。
|
||||
|
||||
## 决策
|
||||
|
||||
根 README 将 DeepSeek Harness 定义为以插件为原生构成单元的 coding agent 运行时，同时交付可组合的 SDK 与组装完成的 `dsh` agent。它将使命定位与已交付事实分开，并首先给出受支持的单行安装命令。
|
||||
只要背后的事实仍然正确，根 README 就保留既有结构、顺序和措辞。刷新时只修正陈旧声明，并补充呈现已交付内容所需的信息；不会因为仓库规模增长就重构整篇叙事。
|
||||
|
||||
安装命令之前的一则说明感谢早期用户，坦率说明内测版本仍未完成、整体完成度还很低，距离团队希望交付的体验还有差距，并邀请用户直接反馈故障、困惑和所有不顺手之处。它明确这些不足是产品的问题，而非用户的问题；紧接其后的预发布提醒则清楚说明兼容性边界。
|
||||
安装说明之前的一则文字感谢内测用户，说明功能和体验仍待完善，并邀请大家通过企业微信群直接反馈失败、困惑和不顺手之处。技术性的预发布声明仍保留在原有的开发章节位置。
|
||||
|
||||
README 列出 TUI、Web、Headless、ACP（Agent Client Protocol）以及 Python/JSON-RPC 入口，并为每个入口提供命令或归属文档链接。它按编码、编排和运维三个类别概述能力，同时说明每种组合都自行选择插件。包与服务的完整清单仍由生成图和包分组文档维护。
|
||||
用户入口章节在已有的 Web、TUI 和 Headless 入口旁补充 ACP（Agent Client Protocol）自动化服务器和 Python/JSON-RPC SDK。能力段落沿用简洁清单的写法，补充已经交付的 PTY、LSP、Web、目标、规划、任务、沙箱、审批、会话查询和遥测等能力类别，并说明不同组合只选用其中一部分。相邻的一条列表项说明权威会话日志规则，因为持久化、回放、查询、遥测和各类接口都依赖它。
|
||||
|
||||
以插件为原生构成单元是 README 的组织原则，而非一句口号：README 通过 `cordis.yml` 将可替换服务、类型化事件与组合方式关联起来，并明确面向模型的行为、持久化、回放、查询、遥测和 UI 投影都以权威会话日志为基础。详细契约仍由架构文档、CLI（命令行界面）、示例、实操手册（cookbook）和生成目录各自维护。
|
||||
|
||||
中英文 README 采用相同的技术结构。两侧的社区章节分别指向各自语言受众的主要交流渠道。文档网站继续使用独立的用户指南首页；仓库 README 不加入该投影。
|
||||
包（package）与服务的完整清单仍由各自的归属文档维护。中英文 README 采用相同的技术结构，但社区章节仍分别指向各自语言受众的主要交流渠道。文档网站继续使用独立的用户指南首页。
|
||||
|
||||
## 考虑过的替代方案
|
||||
|
||||
**只展示组装完成的 coding agent。** 这样能给出最简短的产品介绍，但会让 SDK、其他入口和可替换的运行时 seam 显得无足轻重，尽管它们都是仓库中已经交付的组成部分。
|
||||
**围绕新的产品叙事重写 README。** 完整重写能够突出所有现有入口和能力，但也会替换准确且已经过评审的文案，造成不必要的变动。现有事实能够纳入既有的产品优先结构。
|
||||
|
||||
**将仓库呈现为 SDK 和包清单。** 这样能立即展现实现广度，却会迫使新读者从包名反推出产品。包索引与生成的能力图仍是权威清单。
|
||||
|
||||
**使用包含截图、徽章和重复教程的长篇营销页面。** 富媒体能够展示稳定的产品使用路径，但其内容会独立于命令和源码契约而逐渐陈旧。根 README 保持紧凑，并链接到可运行示例和各自维护的指南。
|
||||
|
||||
**将根 README 投影为文档网站首页。** 使用同一个首页可以避免两套叙事，但文档网站的用户指南与仓库面向开发者和产品的入口在导航和维护需求上并不相同。两者继续作为独立来源，并链接到相同的架构文档和指南。
|
||||
**将根 README 投影为文档网站首页。** 使用同一个首页可以避免两套叙事，但文档网站的用户指南与仓库面向产品和开发者的入口在导航和维护需求上并不相同。
|
||||
|
||||
## 结果
|
||||
|
||||
新读者可以在了解包拓扑之前完成安装或选择运行时入口，SDK 读者也能理解扩展模型，而无需把生成目录复制进正文。任何受影响的命令、入口、预发布边界或高层能力类别发生变化时，README 都必须同步更新；每项声明都可以依据源码或归属文档进行评审核验。
|
||||
评审者可以区分事实更新与编辑性重写；今后的更新会保留既有措辞，除非其含义已经不再正确或完整。受影响的命令、入口、预发布边界或高层能力类别发生变化时，README 仍须同步更新；完整细节则继续以链接方式提供，而不是复制到正文。
|
||||
|
||||
Reference in New Issue
Block a user