From 6de042867570e5c4f5527184bd2271a968959056 Mon Sep 17 00:00:00 2001 From: Eric Rakestraw Date: Wed, 7 Oct 2026 16:17:09 +0000 Subject: [PATCH] Request shared release validation for PromptKit --- docs/roadmap/feature-request-promptkit.md | 182 ++++++++++++++++++++++ 1 file changed, 182 insertions(+) create mode 100644 docs/roadmap/feature-request-promptkit.md diff --git a/docs/roadmap/feature-request-promptkit.md b/docs/roadmap/feature-request-promptkit.md new file mode 100644 index 0000000..444ee08 --- /dev/null +++ b/docs/roadmap/feature-request-promptkit.md @@ -0,0 +1,182 @@ +# Feature Request From PromptKit: Shared Release Validation + +Status: Requested by a prospective downstream consumer; not yet adopted by +ReleaseKit. + +Date: 2026-10-07. + +This request derives from PromptKit's +[ReleaseKit adoption assessment](https://gitea.maximumdirect.net/eric/promptkit/src/commit/7310ef34a44dae7288db7b281e2a6b7f2c56c4e9/docs/roadmap/releasekit.md), +which reviewed ReleaseKit `v0.1.0`. It describes downstream needs and leaves +public API design, shared defaults, and implementation choices to ReleaseKit. + +## Consumer Context And Goal + +PromptKit is a source-only Go library with concurrent LLM execution and +backend-capacity management. It would like to adopt ReleaseKit's common +source-publication process and reduce its own release infrastructure to +product settings and a few substantive project checks. Its existing release +scripts contain 209 lines, most of which implement validation rather than +publication. + +PromptKit accepts changes to its release process in exchange for a common +standard and lower maintenance. The opportunity is to share useful validation +capabilities, rather than preserve every existing shell command or local rule. +Its consumer-example assertions and compatibility decisions remain meaningful +project responsibilities. + +The four primary requests below concern reusable validation. Two additional +candidates are included for evaluation if their wider value justifies shared +support. PromptKit's choices about race testing, full vet, and credential +scanning remain under review; these requests describe useful capabilities +without making their acceptance a prerequisite for adoption. + +## Primary Requests + +### 1. Shared Go Formatting Validation + +Please make Go formatting validation available through ReleaseKit's public +validation API and release profile, so the shared candidate workflow can +report tracked Go source that needs formatting. + +PromptKit currently owns a shell check that identifies its tracked Go files +and verifies their formatting. The operation is common to Go repositories; +maintaining that mechanism independently adds little project-specific value. +A useful shared capability would inspect source, report the affected files, +and leave formatting changes to ordinary development. + +The benefit is consistent validation and diagnostics with less local script +maintenance. PromptKit can follow ReleaseKit's selected formatting convention +without requiring preservation of its current enumeration or command loop. + +### 2. Shared Offline Markdown-Link Validation + +Please make validation of local Markdown links available through the public +validation API and release profile. PromptKit needs checks for local file +destinations and heading fragments, with enough diagnostic context to locate +and correct a broken link. + +Documentation is part of PromptKit's consumer interface. Broken navigation +between its guides, formats, policies, and examples makes otherwise correct +documentation harder to use. Its current local Markdown checker is the +largest generic block in its release-validation script. + +Shared support would remove a locally maintained parser and standardize the +supported Markdown behavior across consumers. ReleaseKit can establish the +supported link and heading conventions; PromptKit does not require its exact +current parsing or anchor rules. Repository-specific choices about links to +material outside the checkout should remain distinguishable from generally +useful local-link validation. + +The desired operation is offline and reports problems without changing +documentation. External website availability is a separate concern and adds +no value to this request. + +### 3. Race Detection Within One Standard Test Run + +Please provide a supported public API and profile choice for race-enabled +execution of the standard full Go suite during candidate validation. + +PromptKit's concurrent execution and capacity management make race detection +useful: ordinary successful tests can miss unsafe shared-state access. Its +current release validation runs the full suite with the race detector. +ReleaseKit's current +[candidate workflow](../consumers/check.md) always runs the ordinary suite; +expressing a race run as an additional check would execute the complete suite +twice. + +The desired capability selects race-enabled execution for that one suite +run, while ReleaseKit continues to own the candidate workflow. The selection +should work consistently through the public API and CLI/profile forms of +candidate checking and publication. A consumer can select the ordinary suite +when that is sufficient. + +This overlaps with ConfigKit's +[base-test invocation request](feature-request-configkit.md#select-one-base-go-test-invocation). +PromptKit would benefit from the same shared capability; it does not need a +separate PromptKit-specific test mechanism. ReleaseKit can decide the smallest +appropriate public expression of the choice and whether race testing belongs +among its common defaults. + +### 4. Shared Full Go Vet Validation + +Please consider exposing full Go vet analysis as part of ReleaseKit's public +validation API and release profile, coordinated with the standard suite. + +PromptKit currently runs full vet separately. Ordinary Go test execution +includes only a subset of vet analyses, so replacing the current procedure +with the standard test run does not provide equivalent static analysis. The +additional analyses can detect defects that are not exercised by tests. + +PromptKit can temporarily retain a configured full-vet command. A shared +capability would let consumers express that validation choice directly and +let ReleaseKit coordinate the analysis with testing to avoid unnecessary +overlap. The desired outcome is full selected analysis and one complete +suite execution; PromptKit leaves the means of achieving that outcome to +ReleaseKit. + +This also overlaps with ConfigKit's +[shared-check request](feature-request-configkit.md#evaluate-shared-release-checks). +Full vet may be useful as a common default or as an explicit selection. +PromptKit is asking for a shared capability, not prescribing additional gates +for every ReleaseKit consumer. + +## Additional Candidates For Evaluation + +### 5. Optional Go Module Distribution Checks + +PromptKit's architecture keeps committed workspace files and local filesystem +module replacements out of its released source. These rules help a shared +library remain independent of neighboring checkouts. Disabling workspace +discovery during validation controls the test environment but does not check +the files being distributed. + +If other consumers have the same need, optional public validation capabilities +could check for committed workspace files and local filesystem replacements. +Consumers should be able to select the distribution rules relevant to them; +a versioned module replacement is different from a local filesystem +dependency, and Go applications may deliberately distribute workspace files. + +The potential benefit is reusable inspection and consistent diagnostics +without each library owning its own checks. PromptKit can also keep a small +local check if that is simpler than introducing shared support. This is a +lower-priority candidate, not a request for universal bans on workspaces, +replacement directives, or vendoring. + +### 6. Optional Recognizable-Credential Checks + +PromptKit's assessment recommends retiring its mandatory credential-pattern +scan, while retaining ordinary credential-aware change review. A viable +alternative is to keep a lightweight automated signal for recognizable +accidentally committed credential formats. + +If ReleaseKit finds broader consumer value in that alternative, please +consider an optional public validation capability for such checks. A useful +offering would make its detection scope clear and account for the possibility +of matching synthetic examples or fixtures. It would complement ordinary +review rather than imply comprehensive detection. + +Shared support could centralize maintenance of the selected detection behavior +and remove another local script fragment. PromptKit is not requesting a +general security-scanning subsystem, preservation of its current regex, or +a mandatory credential gate. This candidate warrants adoption only if its +additional protection justifies its maintenance and false-positive costs. + +## Desired Adoption Outcome + +The strongest opportunities are shared formatting and Markdown validation, +followed by useful race/vet choices within a single candidate-validation flow. +The module-distribution and credential candidates merit separate evaluation +because their policies and benefits vary between consumers. + +For accepted capabilities, availability through both the public Go API and +the maintained CLI/profile would let PromptKit select them without creating +its own release executable. PromptKit can retain its consumer-example +assertions as additional checks and use ReleaseKit's supported conventions +for shared validation and diagnostics. + +PromptKit would continue to prepare its release note and publish its candidate +to authoritative `main` before invoking source publication. Confirmed tag +publication completes the source release; CI and hosted delivery remain +separate. Those responsibilities already fit ReleaseKit's common workflow +and do not require new features for this request.