Define an integration-neutral contract for native event configuration

未关闭
  • 哪里不对？
#5,052 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
35/100
Issue 类型
重构
描述清晰度
描述清楚
活跃度
活跃
技术栈
python
领域
backend, developer-experience

调研方向

Start with IntegrationBase, shared event orchestration, the Vibe integration, and design/integration.md; compare the existing Vibe event handling with one other native-event format. Define and document the integration-neutral contract, then add positive and negative coverage for delegation, ownership, diagnostics, symlink and journal safety, and shared dispatcher lifecycle. Done means all acceptance criteria pass while integrations without native-event support retain their behavior.

由索引模型根据 Issue 内容生成。

描述

triage-can-wait

Problem

Shared event orchestration currently contains agent-specific format branches and knowledge of native configuration layouts. Moving native rendering and cleanup into integration packages improves ownership, but agent-specific branches and method names in shared code leave that boundary incomplete.

The Vibe preservation fix in #4646 illustrates this distinction: native TOML handling can live in VibeIntegration while shared events still explicitly selects Vibe-specific methods.

This is architectural follow-up work, not a prerequisite for accepting that bug fix.

Proposed improvement

Define a small, typed contract on IntegrationBase for merging and removing native event hooks. Possible method names are merge_native_event_hooks() and remove_native_event_hooks(); finalize their signatures against the requirements of existing event-capable integrations.

Shared orchestration should own canonical event filtering, shared dispatcher creation and reference-counted cleanup, and manifest bookkeeping. Integrations should own native event-name mapping, configuration rendering and merging, managed-entry recognition, and cleanup.

The contract should provide access to shared dispatcher-command construction and safe, journal-aware filesystem operations without requiring integrations to reproduce shared lifecycle behavior.

Acceptance criteria

  • Shared orchestration delegates native configuration updates and cleanup through declared, integration-neutral methods, without Vibe-specific branches or dynamic discovery of Vibe-named methods.
  • Validate the contract against Vibe and at least one other existing native-event format. Existing format implementations may remain behind base-class defaults; migrating every integration is not required.
  • Integrations without native-event support retain their existing behavior.
  • The update result distinguishes files actually updated from untouched or skipped files. Failures and skipped updates produce explicit diagnostics.
  • Merged user configuration retains partial ownership; untouched files do not acquire new ownership claims.
  • Disabling events and uninstalling remove only Spec Kit-managed entries, preserve unowned content, and retain the dispatcher while another integration references it.
  • Preserve symlink protections and lifecycle-journal participation.
  • Add positive and negative contract coverage, including no-op preservation and multi-integration dispatcher lifecycle. Any bug fixes include before-and-after regression evidence.
  • Document the contract and ownership boundary in design/integration.md.

Out of scope

  • Changes to native hook schemas or supported events.
  • Changes to core command templates.
  • A new event plugin framework.
  • Wholesale migration of every integration’s native event implementation.

AI disclosure

GitHub Copilot, powered by GPT-6.1 Sol (gpt-6.1-sol), drafted this issue under human supervision. The user reviewed the draft and authorized filing it upstream. AI assistance covered PR inspection, architectural analysis, and issue drafting; no implementation changes were made.

主要语言
Python
星标
149k
派生
13.4k
平均合并
1 天 5 小时
30 天内合并 PR
223

环境准备

在 Codespaces 中打开

在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

github/spec-kit 的其他 Issue

查看 github/spec-kit 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。