Request shared release validation for PromptKit

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.