Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

[Feature]: Add deterministic contribution IDs and stack lookup IDs for resolved artifacts

Offen
  • Stimmt etwas nicht?
#4,210 11 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

  • #4261 von @nicolehaugen — ohne Merge geschlossen

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
38/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
python
Bereich
cli, documentation, testing, tooling

Rechercherichtung

Beginne mit dem Schema und der Validierung des Extension-Manifests und verfolge dann die Kompositionsverarbeitung in PresetResolver für Provenance-gestützte Layer. Lies extensions/EXTENSION-API-REFERENCE.md sowie die Referenz zu Preset API/Manifest und führe die vorhandenen Schema- und Resolver-Tests aus. Erledigt bedeutet, dass deterministische IDs und lookupId-Beziehungen für alle aufgeführten Artefaktarten, Hooks, integrierten Elemente, Überschreibungen und Kompatibilitätsfälle abgedeckt sind.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

enhancement feature-assess feature-go
Problem Statement

Spec Kit identifies contributed commands, templates, scripts, and hooks primarily by name. Names can collide across artifact kinds and source layers, and a name alone cannot reliably link a resolved artifact-stack layer to the exact manifest contribution that supplied it. Consumers such as preset info --json, extension info --json, and specify artifact need stable contribution identifiers and a join key that works across reinstalls and machines.

Proposed Solution

Introduce computed, opaque id fields for every command, template, script, and hook returned by public preset/extension manifest and info APIs, plus a lookupId field on every provenance-backed non-built-in resolved artifact-stack layer.

For named preset, extension, and project-override contributions, derive IDs using:

{layer}:{sourceId}:{kind}:{name}

Use project, preset, or extension for layer; _ only for the project-override source ID; and the preset or extension manifest ID for manifest-declared sources. Use command, template, or script for kind. Examples include preset:speckit.core:command:speckit.plan, extension:speckit.git:template:pr-body, and project:_:template:spec-template.

For hooks, use {eventName}:{command} as the name component. Hooks are valid only for preset and extension layers. If duplicate event/command hook entries are valid, add an appropriate stable discriminator or reject duplicates; do not use array position.

Built-in artifacts do not have an originating manifest contribution and therefore do not receive a contribution lookupId. Every artifact, including built-ins, instead has a source-agnostic public ID of the form {kind}:{name}. Built-in stack rows are recognized by absent provenance fields (layer, sourceId, and lookupId are null), and round-trip through the public artifact ID.

Compute IDs at read, serialization, or resolution time rather than persisting them in authored or installed manifests. For manifest-declared preset and extension layers, lookupId must exactly match the originating contribution's id. Preserve existing name-based behavior and document IDs as opaque strings.

Alternatives Considered

Install-time UUIDs are unsuitable because they differ across machines and reinstalls. Existing names are insufficient because they collide across sources and kinds. Content hashes are unsuitable because IDs would change whenever artifact content is edited. Array indexes are unsuitable for hooks because reordering entries would change their IDs.

A synthetic core:_:... contribution ID was considered for built-in assets. It was rejected because built-ins have no originating preset or extension manifest contribution to join to; the source-agnostic {kind}:{name} artifact ID provides their stable round-trip key without overloading lookupId.

Do not use the existing integration manifest as the ID source; it tracks installed file hashes and paths rather than manifest contribution identity.

Component

Specify CLI (initialization, commands)

AI Agent (if applicable)

No response

Use Cases
  1. A wizard can read an artifact stack and follow each provenance-backed layer's lookupId to the full contribution detail without re-parsing manifests.
  2. Developers on different machines can use identical IDs when reporting or diagnosing a contribution.
  3. Tooling can hash or cache resolved compositions using public artifact IDs plus the available layer lookupId values.
  4. Future JSON output for preset info, extension info, and specify artifact can expose consistent cross-references.
Acceptance Criteria
  • Document the layer:sourceId:kind:name contribution grammar, the source-agnostic kind:name artifact ID, and the lookupId relationship in extensions/EXTENSION-API-REFERENCE.md and the preset API/manifest reference.
  • Public preset/extension manifest and info representations expose computed id values for commands, templates, scripts, and hooks.
  • Hook IDs are deterministic and collision-free without install paths or list indexes.
  • Manifest-declared preset and extension artifact-stack layers expose lookupId equal to the corresponding contribution's id.
  • Project-local override layers use the synthetic project:_:{kind}:{name} lookup form and intentionally have no manifest contribution match.
  • Built-in artifact-stack layers expose no contribution provenance (layer, sourceId, and lookupId are null) and round-trip through the public {kind}:{name} artifact ID.
  • Identical manifest coordinates produce identical IDs across processes, machines, project locations, and reinstalls.
  • Manifest-backed IDs do not depend on artifact contents, timestamps, manifest hashes, archive paths, or installation directories.
  • Existing name fields and name-based resolution remain unchanged.
  • Tests cover each provenance-backed layer and artifact kind, hook uniqueness, resolver repeatability, manifest lookup round-trips, built-in public-ID round-trips, and backward compatibility.
Additional Context

This request defines the ID contract only. Adding the JSON output surfaces themselves for preset info --json, extension info --json, or specify artifact is out of scope and will be handled separately. Changing precedence, resolution, installation, or uninstall behavior is also out of scope. Relevant implementation areas include the extension manifest schema and validation and PresetResolver composition handling. IDs must not expose install paths, secrets, or connection strings.

Vorherrschende Sprache
Python
Sterne
140k
Forks
12.6k
Ø Merge
2 T. 11 Std.
Gemergte PRs (30 T.)
186

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.