fix: address repository removal review
This commit is contained in:
Turtle
+2
-2
@@ -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/simplification/2026-08-09-remove-repository-plugin.md
|
||||
2026-08-09-remove-repository-plugin.md: 8dd2fe95ac97bc2d8ab50043eb6c516f53d3204c
|
||||
2026-08-09-remove-repository-plugin.zh.md: 832a69ff206dd91dd312625bd9218e980d890ae2
|
||||
2026-08-09-remove-repository-plugin.md: 8ac6fd18b756e227f8dabc82eb4926a51702c5a1
|
||||
2026-08-09-remove-repository-plugin.zh.md: 6e504a151a88b87b8093a91a91ede1cb919a0b45
|
||||
@@ -26,7 +26,7 @@ This note consolidates the removed repository cache, static format, config-only
|
||||
|
||||
**Teach the repository wrapper to load a bundle patch.** Rejected because the repository cache and preparation protocol would still duplicate profile dependency installation. Bundle packages are already accepted from npm, Git, file, and link specifications through pnpm.
|
||||
|
||||
**Keep the generic Loader repository cache for possible future consumers.** Rejected because it has no current consumer after the package removal and carries a pinned package-manager runtime in a vendored browser-adjacent package. A future need can choose its cache contract from current consumers rather than preserving this one speculatively.
|
||||
**Keep the generic Loader repository cache for possible future consumers.** Rejected because it has no current consumer after the package removal and carries a pinned package-manager runtime in a vendored browser-adjacent package. A dedicated cache is warranted again only if configuration-time activation without an explicit installation becomes a product requirement that profile dependencies cannot satisfy; that consumer can choose its cache contract then.
|
||||
|
||||
**Disable repository Plugin but retain its on-disk format for migration.** Rejected under the pre-release stance. Retaining a parser or compatibility loader would keep the removed contract alive without an external compatibility obligation.
|
||||
|
||||
@@ -34,10 +34,11 @@ This note consolidates the removed repository cache, static format, config-only
|
||||
|
||||
- Third-party packages use one installation and composition model, with ordinary dependency declarations and full patch-level Plugin config.
|
||||
- Installing or updating an external bundle is an explicit `dsh plugin` package-manager operation rather than a watched source-list edit. User patch HMR still configures rows contributed by installed bundles.
|
||||
- Profile installation requires `pnpm` on the host `PATH`. This is acceptable for an explicit package-management operation and avoids shipping the removed cache's pinned package-manager runtime solely for configuration-time activation.
|
||||
- `.dsh-plugin` packages and existing repository source-list patches stop working. Their cache files remain removable by the user but are not migrated or automatically deleted.
|
||||
- The dedicated pnpm runtime, preparation executable, wrapper generator, Git credential CI setup, repository cache, and repository-specific tests disappear.
|
||||
- Package-relative static assets need a bundle-owned path form so a declarative bundle can point `dsh-skill-local`, `dsh-mcp-client`, or another Plugin at files it ships without custom runtime glue. That capability is owned by the bundle format rather than a repository adapter.
|
||||
|
||||
## Testing
|
||||
|
||||
Static gates reject stale package, config, documentation, graph, and workspace references. The existing `dsh plugin` built-CLI acceptance covers profile initialization, package-manager installation, bundle discovery, and layer reconciliation. Bundle-specific tests own declarative asset-path resolution and real Skill/MCP composition.
|
||||
Static gates reject stale package, config, documentation, graph, and workspace references. The existing `dsh plugin` built-CLI acceptance covers profile initialization, package-manager installation, bundle discovery, and layer reconciliation. Declarative package-relative Skill and MCP bundle resources remain a named coverage gap in this removal layer.
|
||||
@@ -26,7 +26,7 @@ DeepSeek Harness 只保留一种独立的外部插件分发路径：可安装的
|
||||
|
||||
**让 repository 包装层加载组合包 patch。** 不予采纳，因为 repository 缓存和准备协议仍会重复 profile 依赖安装。组合包已经可以通过 pnpm 接受 npm、Git、file 和 link 说明符。
|
||||
|
||||
**为未来可能出现的消费方保留通用 Loader repository 缓存。** 不予采纳，因为在移除相关包后，它已无当前消费方，却仍让一个 vendor 中与浏览器相邻的包携带固定版本的包管理器运行时。未来若确有需要，可以根据届时的实际消费方选择缓存契约，无需推测性地保留现有契约。
|
||||
**为未来可能出现的消费方保留通用 Loader repository 缓存。** 不予采纳，因为在移除相关包后，它已无当前消费方，却仍让一个 vendor 中与浏览器相邻的包携带固定版本的包管理器运行时。只有当无需显式安装即可在配置阶段激活这一能力成为 profile 依赖无法满足的产品需求时，才有理由重新引入专用缓存；届时该消费方可以选择自己的缓存约定。
|
||||
|
||||
**禁用 repository 插件，但保留其磁盘格式以供迁移。** 根据预发布方针，不予采纳。保留解析器或兼容 loader 会在没有外部兼容义务的情况下，让已移除的契约继续存在。
|
||||
|
||||
@@ -34,10 +34,11 @@ DeepSeek Harness 只保留一种独立的外部插件分发路径：可安装的
|
||||
|
||||
- 第三方包统一使用一种安装与组合模型，采用普通依赖声明和完整的 patch 层插件配置。
|
||||
- 安装或更新外部组合包时，必须显式通过 `dsh plugin` 执行包管理器操作，而不是编辑受监听的源列表。用户 patch 的 HMR（热模块替换）仍可配置已安装组合包所提供的配置项。
|
||||
- 安装 profile 时，宿主机的 `PATH` 中必须提供 `pnpm`。对于显式的包管理操作，这一要求可以接受，并且可避免仅为配置阶段激活而随产品交付已移除缓存所使用的固定版本包管理器运行时。
|
||||
- `.dsh-plugin` 包和现有 repository 源列表 patch 停止工作。用户仍可自行删除其缓存文件，但系统不会迁移或自动删除这些文件。
|
||||
- 专用 pnpm 运行时、准备工作可执行文件、包装层生成器、Git 凭据 CI 设置、repository 缓存和 repository 专用测试全部消失。
|
||||
- 静态资源需要一种由组合包拥有、可相对于包解析的路径形式，使声明式组合包可以将 `dsh-skill-local`、`dsh-mcp-client` 或其他插件指向它随包交付的文件，而无需定制运行时代码。该能力归组合包格式所有，而不是 repository 适配器。
|
||||
|
||||
## 测试
|
||||
|
||||
静态门禁会拒绝残留的包、配置、文档、图和 workspace 引用。现有 `dsh plugin` 已构建 CLI（命令行界面）验收测试覆盖 profile 初始化、包管理器安装、组合包发现和层调和。组合包专用测试负责覆盖声明式资源路径解析，以及真实的 skill／MCP 组合。
|
||||
静态门禁会拒绝残留的包、配置、文档、图和 workspace 引用。现有 `dsh plugin` 已构建 CLI（命令行界面）验收测试覆盖 profile 初始化、包管理器安装、组合包发现和层调和。声明式、相对于包解析的 skill 与 MCP 组合包资源仍是本移除层中已明确记录的覆盖缺口。
|
||||
@@ -33,12 +33,8 @@ export const inject = ['tools']
|
||||
/** Default timeout for individual MCP tool calls (ms). */
|
||||
const DEFAULT_TOOL_CALL_TIMEOUT_MS = 60_000
|
||||
|
||||
/**
|
||||
* Valid `serverName`: 1–32 chars of `[A-Za-z0-9_-]`. Kept well under the
|
||||
* 64-char public-name budget so typical raw tool names survive unhashed.
|
||||
* Exported so config producers can reject the same names this registry would.
|
||||
*/
|
||||
export const SERVER_NAME_PATTERN = /^[A-Za-z0-9_-]{1,32}$/
|
||||
/** Valid `serverName`, kept below the public tool-name budget. */
|
||||
const SERVER_NAME_PATTERN = /^[A-Za-z0-9_-]{1,32}$/
|
||||
|
||||
/**
|
||||
* Live `serverName` reservations per app, keyed off `ctx.root` (multiple apps
|
||||
|
||||
@@ -830,7 +830,7 @@ describe('LocalSkillProvider', () => {
|
||||
|
||||
// Isolated providers see only their explicit roots: the environment
|
||||
// bundled root is a default root, so includeDefaultRoots: false must
|
||||
// drop it — repository providers never re-claim the app's builtins.
|
||||
// drop it — isolated providers never re-claim the app's builtins.
|
||||
const isolated = new Context()
|
||||
await isolated.plugin(SkillService)
|
||||
const customOnly = join(envHome, 'custom-only')
|
||||
|
||||
@@ -32,7 +32,6 @@
|
||||
"cosmokit": ["./vendor/cosmokit/src"],
|
||||
"schemastery": ["./vendor/schemastery/src"],
|
||||
"@cordisjs/plugin-loader": ["./vendor/loader/src"],
|
||||
"@cordisjs/plugin-loader/repository": ["./vendor/loader/src/repository.ts"],
|
||||
"@cordisjs/plugin-include": ["./vendor/include/src"],
|
||||
"@cordisjs/plugin-group": ["./vendor/group/src"],
|
||||
"@cordisjs/plugin-timer": ["./vendor/timer/src"],
|
||||
|
||||
Reference in New Issue
Block a user