Define an integration-neutral contract for native event configuration

Offen
  • Stimmt etwas nicht?
#5,052 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
35/100
Issue-Typ
Refactoring
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
python
Bereich
backend, developer-experience

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
Python
Sterne
149k
Forks
13.4k
Ø Merge
1 T. 5 Std.
Gemergte PRs (30 T.)
223

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus github/spec-kit

Alle Issues in github/spec-kit

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.