Uh oh!
There was an error while loading. Please reload this page.
feat(spec)!: 删除 trigger-registry 的 Connector 簇 —— 同一业务需求的第三份声明，文件名承诺的东西从未存在 (#4499) - #4503
Merged
Merged
Conversation
BREAKING CHANGE: @objectstack/spec/automation no longer exports the third declaration of the connector vocabulary — ConnectorSchema, ConnectorInstanceSchema, ConnectorOperationSchema, ConnectorTriggerSchema, ConnectorCategorySchema, the Authentication*/OAuth2Config/Operation* family, their inferred types, and the Connector.apiKey()/.oauth2() factory helpers. All 630 lines of automation/trigger-registry.zod.ts go, plus its test and generated reference page. Despite the filename the file contained no trigger registry: every export was connector vocabulary, self-contained and read by nothing. The automation engine registers and validates connectors against ConnectorSchema from integration/connector.zod.ts (ADR-0097) and never imported this one; the stack `connectors:` collection parses DeclarativeConnectorEntrySchema; outside the spec package the only references in the monorepo were the two doc generators that published it. A full dependent typecheck (119 tasks) passes with the file gone — the compiler confirms the zero-consumer verdict. This closes the connector triple-declaration (Prime Directive #12): the ADR-0097 contract is the one spelling, the six per-provider templates fell in #4480, this was the last copy. integration/connector.zod.ts's header loses its "When to use Integration Connector vs. Trigger Registry?" section with it — guidance that steered lightweight cases to a dead file with the platform's authority, the same defect class as the capabilities.readOnly prescription corrected in #4487. The removal kit, same shape as #4480: - automation/index.ts barrel line removed with a note recording the decision - authorable-surface.json: 69 keys deleted deliberately (gate (a)'s strict- removal trip wire); json-schema.manifest.json: 11 entries - build-docs page list and build-skill-references source list pruned; reference pages, skill references, api-surface regenerated (the references/automation/connector.mdx page survives with only the live DataSyncConfig on it) - strictness ledger: row dropped per the checker's contract, prose note keeps the audit trail (the old row's "descriptors are code-registered; bindings authored" was optimistic twice over); automation section total 99 → 88 - PROTOCOL_MAP row, quick-reference row, v17 dead-clusters row - major changeset with the name-collision warning: the live module also exports ConnectorTriggerSchema/Connector with different shapes, so an import-path find-and-replace is not a migration No D2 conversion: none of this was storable stack metadata, so there is no source for `os migrate meta` to rewrite. Closes#4499 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WsgTqRF58HsQYKLsrZ5pQY
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
os-zhuang
enabled auto-merge
August 1, 2026 13:20
Contributor
📓 Docs Drift CheckThis PR changes 1 package(s): 107 hand-written doc(s) reference the affected code and may need an implementation-accuracy re-verification:
|
Uh oh!
There was an error while loading. Please reload this page.
os-zhuang pushed a commit
that referenced
this pull request
Aug 1, 2026
…olved Second catch in one afternoon, this time inside the merge queue: the queue built this branch against a main that had just landed #4503 (trigger-registry Connector cluster removal), which deleted the ./automation copies of Connector, ConnectorSchema and ConnectorTriggerSchema — and the gate refused the queue build until their baseline lines were gone. 55 → 52. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M9uWvoEp9CoLzYjNExj9sL
akarma-synetal pushed a commit
to akarma-synetal/framework
that referenced
this pull request
Aug 2, 2026
…erent declaration, judged by symbol identity (objectstack-ai#4446) (objectstack-ai#4506) * feat(spec): ratchet cross-entry dual-source exports — same name, different declaration, judged by symbol identity (objectstack-ai#4446) api-surface.json records every export per entry point, so a name appearing on two entries was VISIBLE — but nothing distinguished the two ways that happens, and only one of them is fine: a re-export (one declaration, two import paths) versus a DUAL-SOURCE (each entry resolving the shared name to its own declaration, so which type a consumer gets depends on nothing but the import path). The dual-source case is the objectstack-ai#4411 trap: eleven names declared twice across ./kernel and ./system, where the copy that LOOKED canonical was the dead one — a pick by name compiled and failed later, at an edge value. New pure check `check:dual-source-exports`: - Judged by SYMBOL IDENTITY, not name: every export of all 16 public entries is resolved through its alias chain to the original symbol; a name whose entries resolve to >=2 distinct symbols is dual-source. Name-based counting would drown the signal — the real surface carries 148 legitimately re-exported names next to the 63 real findings. - Shrink-only baseline (dual-source-exports.baseline.json) records the 63 existing dual-sources — including the MetadataFormat ./shared≠./system enum divergence, the ./contracts third-shape interfaces, and two type-vs-const cases (ShareRecipientType, TransformType) the name-level scan could not even see. A NEW dual-source fails with the fix at the declaration (converge + re-export, or rename); a resolved one fails until its line is deleted. The baseline is hand-edited under review, deliberately NOT generated: a `gen:` that rewrites it would admit new dual-sources via "run the fix command" instead of via a maintainer decision. - Self-tests first (the check-exported-any pattern), pinning both edges: a fixture dual-source (incl. type-vs-const) must be flagged, a re-export must not, and count assertions keep a resolution failure from reading as clean. - Wired everywhere a new check must be: package.json, the check:generated reconciliation ledger (NO_GENERATOR — it would fail the run unclassified), lint.yml's TypeScript Type Check job after the build step, and the AGENTS.md pure-checks paragraph. Also fixes a fresh flake this work kept tripping over: the objectstack-ai#4491 parity tests spawn a tsx subprocess that loads the whole spec surface (~4.5s alone, 5-7s under turbo's parallel load) against vitest's 5s default timeout — three consecutive full-suite runs failed a DIFFERENT test of that file each time, every one a timeout, while the file alone stayed green. The six spawning tests now carry an explicit 60s timeout: a timeout there should mean "the script hung", not "the runner was busy". Closesobjectstack-ai#4446. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M9uWvoEp9CoLzYjNExj9sL * chore(spec): shrink the dual-source baseline by the 8 pairs objectstack-ai#4500 resolved First contact with reality, one merge in: objectstack-ai#4500 removed the connector "template" cluster, deleting the ./integration copies of ConsumerConfig, DatabaseProvider, MessageQueueProvider and MultipartUploadConfig (type + Schema each). Those 8 names are no longer dual-source, and the gate's stale-entry leg refused to pass until their baseline lines were deleted — the shrink-only ratchet ratcheting down exactly as designed. 63 → 55. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M9uWvoEp9CoLzYjNExj9sL * chore(spec): shrink the dual-source baseline by the 3 pairs objectstack-ai#4503 resolved Second catch in one afternoon, this time inside the merge queue: the queue built this branch against a main that had just landed objectstack-ai#4503 (trigger-registry Connector cluster removal), which deleted the ./automation copies of Connector, ConnectorSchema and ConnectorTriggerSchema — and the gate refused the queue build until their baseline lines were gone. 55 → 52. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M9uWvoEp9CoLzYjNExj9sL --------- Co-authored-by: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes#4499
结论
automation/trigger-registry.zod.ts全文件删除：630 行、11 个 schema、两个工厂 helper、一个测试文件、一张生成的 reference 页。两个独立的事实叠在一起：
ConnectorSchema/Authentication*/Operation*/ConnectorInstance/Connector.apiKey()）。integration/connector.zod.ts（ADR-0097，engine.ts:1379）；stackconnectors:集合走DeclarativeConnectorEntrySchema；monorepo 里 spec 之外唯一引用它的是两个文档生成器 —— 发布渠道，不是消费者。三份声明的收束（Prime Directive #12 — one capability, one contract）：
integration/connector.zod.ts（ADR-0097）integration/connector/*六个 per-provider 模板automation/trigger-registry.zod.ts本簇顺带修掉的假路标
integration/connector.zod.ts的文件头挂着一节 "When to use Integration Connector vs. Trigger Registry?"，用平台的口吻把"轻量场景"指向这个死文件。和 #4487 修掉的capabilities.readOnly处方同病：路标必须指向被强制执行的地方。该节替换为一段记录这次移除的说明，轻量场景就地解决（简单auth的 connector 实例，或sync.zod.ts/etl.zod.ts）。值得记录的两点
1. tsc 是最好的清道夫，这次它真的抓到了东西 —— 只是不是我的。 全依赖 typecheck（119 个任务）first-run 失败在 CLI，stash 我的改动后同样失败 —— 是 worktree 的 node_modules 落后于 main 新加的
@objectstack/metadata-protocol依赖，pnpm install后 119/119 全绿。这次全量 typecheck 同时是本删除"零消费者"判定的编译器级确认。2. 迁移说明里有一个名字撞车陷阱。 活模块
integration/connector.zod.ts也导出ConnectorTriggerSchema和Connector类型，但形状不同（ADR-0097 实例语义 vs 这份的 category/operations 词汇）。所以"把 import 路径查找替换一下"不是迁移 —— changeset 里明确写了这一点。移除套件（与 #4480 同型）
automation/index.tsauthorable-surface.json有意删除 69 行（gate (a) 绊线）；json-schema.manifest.json删 11 条build-docs.ts页面列表、build-skill-references.ts源列表；重新生成后trigger-registry.mdx消失，references/automation/connector.mdx保留但只剩活着的DataSyncConfig（生成器自己收敛的，不是手改）PROTOCOL_MAP.md行、quick-reference 行、v17 dead-clusters 行、major changesetos migrate meta无源可改写验证
@objectstack/spec— 279 files / 7041 tests passed@objectstack/service-automation— 624 tests passed（ADR-0097 活路径不受影响）Generated by Claude Code