Add v0.3 GitHub integration release plan and tickets
This commit is contained in:
+32
@@ -0,0 +1,32 @@
|
||||
# 01 GitHub Provider Foundation and Auth Strategy
|
||||
|
||||
## Goal
|
||||
|
||||
Introduce GitHub as the second concrete Git provider behind the existing provider abstraction while keeping the first GitHub auth mode aligned with KanbanGit's current per-user connection model.
|
||||
|
||||
## Requirements
|
||||
|
||||
- Add GitHub as a supported provider key and provider client.
|
||||
- Target GitHub Cloud on `https://api.github.com`.
|
||||
- Keep project, ticket, and repository-connection core logic free from GitHub-specific assumptions wherever possible.
|
||||
- The provider client must support the API surface needed for:
|
||||
- authenticated user metadata
|
||||
- repository listing
|
||||
- repository lookup
|
||||
- branch listing
|
||||
- pull request listing
|
||||
- The release must choose one initial GitHub auth strategy and document it clearly.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- The codebase has a clear GitHub provider implementation behind the existing provider boundary.
|
||||
- GitHub-specific HTTP details do not leak into ticket or project core logic.
|
||||
- The selected GitHub auth strategy is compatible with the current `UserGitConnection` concept.
|
||||
- The provider foundation is sufficient for later repository linking, branch discovery, and pull request visibility tickets in release `0.3`.
|
||||
|
||||
## Out of Scope
|
||||
|
||||
- GitHub App JWT handling
|
||||
- GitHub installation tokens
|
||||
- GitHub Enterprise Server support
|
||||
- Webhook processing
|
||||
Reference in New Issue
Block a user