4.2 KiB
Promptkit Feature Request: Read-Only Publication Reconciliation
Consumer Context
Promptkit uses ReleaseKit v0.7.0 as a module-selected Go tool for candidate validation, source-tag publication, and page-only Gitea delivery. Source publication and hosted delivery have separate outcomes. A successful intended tag push completes the source release without waiting for CI or module availability.
ReleaseKit already reconciles an unsuccessful push with a bounded authoritative query. This request concerns later recovery when that observation remains unknown and the maintainer can investigate again after connectivity or authentication is restored.
Current Pain Point
Promptkit's runbook reproduces a manual recovery procedure: retain the captured publication endpoint, version, candidate commit, and tag object; check that Git URL rewriting still resolves the endpoint to itself; query the exact tag; then interpret whether the original tag was published, absent, conflicting, or still unobservable.
That procedure is generic release logic, rather than Promptkit-specific policy. Keeping it in each consumer's instructions adds maintenance and opportunities for mistakes. Querying the current remote instead of the original captured endpoint can establish the wrong outcome after configuration changes.
Credential-safe diagnostics introduce an additional handoff issue: a displayed HTTP(S) endpoint can have its userinfo redacted. That display is not necessarily a usable transport URL, and asking an operator to reconstruct the original endpoint from it is inconvenient. Consumers should not need to parse diagnostic text or independently implement ReleaseKit's Git observation rules.
Requested Capability
Please consider a first-class, read-only CLI operation for reconciling a previous
source-publication attempt. A name such as reconcile or publication-status
would be suitable; the exact command and interface are for ReleaseKit to choose.
A corresponding public Go API could serve library consumers with the same need.
The capability would use the original attempt's evidence, including the exact captured endpoint, complete Git tag, intended tag-object identity, and candidate commit as applicable. It should:
- Classify confirmed publication, authoritative absence, a conflicting tag, and an unresolved observation using ReleaseKit's existing publication semantics.
- Preserve the distinction between the annotated tag object and its peeled source commit; a commit match alone does not establish the intended tag object.
- Account for endpoint rewriting and configuration changes rather than silently substituting the current remote destination. An observation failure or insufficient original evidence should remain unresolved.
- Offer a practical handoff of attempt evidence without requiring consumers to parse human-readable output or retype a credential-bearing URL from a redacted diagnostic. Authentication can remain locally supplied, and displayed endpoints should retain the existing credential-safe treatment.
- Return documented, actionable outcomes for operators and automation.
Promptkit has no preference for a particular evidence-storage format or internal implementation. Explicit inputs or a reusable attempt record could meet the need; the important property is that recovery refers to the original attempt.
Scope And Workflow
This is a diagnostic operation after a failed or uncertain publication. It would observe remote state without creating, pushing, moving, or deleting tags; changing branches; publishing hosted pages; or rerunning candidate validation. Any subsequent corrective action would remain explicit.
It would not become a read-back gate after a successful push or a prerequisite for ordinary publication. CI status, consumer retrieval, and hosted-page delivery would remain separate concerns. There is no request for a combined publish-and- deliver command, automatic tag cleanup, or a new release approval step.
Expected Benefit
Promptkit could replace its copied Git query and comparison instructions with one upstream-owned command and a short recovery link. Other ReleaseKit consumers could use the same classifications and credential-safe evidence handoff, reducing both duplicated instructions and divergent recovery behavior.