Define an integration-neutral contract for native event configuration

Aberta
  • Algo errado?
#5,052 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
35/100
Tipo de issue
Refatoração
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
python
Domínio
backend, developer-experience

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Python
Estrelas
149k
Forks
13.4k
Merge médio
1d 5h
PRs com merge (30d)
223

Preparar o ambiente

Abrir no Codespaces

Inicia o contêiner de desenvolvimento do projeto no navegador, com a sua própria conta do GitHub.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de github/spec-kit

Todas as issues de github/spec-kit

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.