[Architecture] Feature — Multi-Provider Support (GitLab, Gitea, etc.)

[0xheartcode]

Overview

lazydash currently only works with GitHub via the gh CLI. Many developers work across multiple platforms — GitHub for open source, GitLab for work, Gitea/Forgejo for self-hosted projects. No existing terminal tool lets you browse project boards across all of these in one unified interface.

Current State

Only GitHub is supported. No abstraction layer exists for multiple backends.

Proposed Solution

The provider interface (from the Provider Interface issue) is the foundation. Each platform gets its own implementation:

provider/
  provider.go       -- interface + shared types
  github/
    github.go       -- GitHub implementation
  gitlab/
    gitlab.go       -- GitLab implementation
  gitea/
    gitea.go        -- Gitea implementation

The TUI never imports a specific provider directly. Providers are configured in the config file:

providers:
  - type: github
    orgs: ["myorg"]
  - type: gitlab
    host: gitlab.company.com
    token: $GITLAB_TOKEN
  - type: gitea
    host: gitea.internal.dev
    token: $GITEA_TOKEN

Because all providers output the same normalized types, the TUI, cache, search, and any external consumer all work identically regardless of data source.

Sequencing

Don't build GitLab or Gitea support now. Get the provider interface right with just GitHub first. Once the interface is solid and proven through real usage, adding a new backend is mechanical.

Priority

Do third, after the cache and search are working. The interface must exist first.

Acceptance Criteria

• Provider interface is generic enough to support non-GitHub backends
• Config file supports multiple provider entries
• At least one additional provider stub (GitLab or Gitea) demonstrates the pattern
• TUI code never imports a specific provider directly

Epic: This is an epic-sized issue that will need to be broken down into smaller sub-issues when work begins.

[0xheartcode]

🏗️ Epic Notice

This is an epic-sized issue — adding a full multi-provider abstraction with config-driven provider selection, at least one additional backend stub, and ensuring the TUI is fully provider-agnostic. Will need to be broken down into smaller sub-issues when work begins.

Depends on: #15 (Provider Interface) must be completed first.