feat: prepare standalone site target compatibility - #283
Open
jlitola wants to merge 4 commits into
Open
Conversation
Accept site as a resolve target preference and render standalone documentation-site candidates as a known target kind.\n\nUpdate CLI guidance and release metadata for the backend compatibility rollout.
Retain package and repository product wording until backend site projection is activated.\n\nDescribe this release as forward compatibility while preserving SITE parsing and formatting.
Continue accepting the reserved SITE value without advertising it in validation guidance before backend activation.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
GitHits can now safely send and render the reserved standalone-site target kind when the backend begins returning it. Existing product help and examples continue to advertise package and repository resolution only, so this is a compatibility release rather than feature activation.
Why
The backend must deploy additive
SITEcompatibility before standalone-site projection is enabled. Existing clients remain safe because result kinds are string-tolerant, but they cannot request aSITEpreference and render a future site candidate with the generictargetlabel. This PR adds first-class behavior for new versions without making client rollout a backend compatibility gate.This PR is the companion client slice for the PkgSeer Phase 2 compatibility release. It does not advertise standalone-site resolution or activate any backend site writer.
Companion backend compatibility: https://github.com/githits-com/pkgseer-backend/pull/1781
Changes
SITEto the shared resolve-target request kind.siteinternally as a preferred-kind value while retaining the currently advertised package/repository help and invalid-value wording.Verification
bun test packages/core-internal/src/services/resolve-target-service.test.ts packages/mcp/src/shared/resolve-target-request.test.ts packages/mcp/src/shared/resolve-target-response.test.ts src/commands/resolve.test.ts— 44 passed.bun test packages/mcp/src/shared/resolve-target-request.test.ts— final wording check, 6 passed.bun run build,bun run format:check,bun run lint, andbun run typecheckpassed.bun run smoke:cli --mode unauthenticatedandbun run smoke:mcp --mode registrationpassed.bun run smoke:cli:builtandbun run smoke:mcp:builtpassed.Compatibility / Risks
SITEremains dormant in product-facing help and examples. This client release is not a prerequisite for the companion backend: older versions already parse candidate kinds as strings and render an unknown kind as a generictarget. The client and backend releases can deploy independently; the backend keeps site projection disabled and requires zero projected site rows until the later activation phase.