81 lines
4.2 KiB
Markdown
81 lines
4.2 KiB
Markdown
|
# 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.
|