Connector reliability: rebuild GitHub/repo identity and Daytona integration

[teckedd-code2save]

Why

Connectors are currently too loose to support GroundControl's agent-native direction. GitHub/repository linking is buggy and ambiguous, connector health can report "connected" while a required capability is broken, and Daytona has not completed a reliable end-to-end acceptance flow.

This is intentionally parked behind the current agent-access milestone so it stays visible without expanding that scope.

Track 1 — GitHub + repository identity

Rebuild the relationship between:

• GroundControl user/account
• GitHub App installation / credential grant
• repository
• branch/revision
• GHCR/package access
• enrolled deployment
• deployment target

Acceptance:

1. Connect GitHub once through a predictable installation/auth flow.
2. Discover private/public repositories available to that installation.
3. Link an exact repository to an enrolled deployment.
4. Resolve branch + deployed revision deterministically.
5. Verify repository read access and GHCR/package access independently.
6. A connector is never called connected merely because credentials exist.
7. Expired/revoked/package-insufficient credentials become degraded with an exact remediation.
8. Reconnect/rotate credentials without breaking deployment identity.
9. Fold issue Detect expired GitHub package credentials before deployment #82's registry credential checks into this capability-health model.

Track 2 — Capability health

Expose per-capability status rather than one connector boolean, e.g.

{
  "connector": "github",
  "capabilities": {
    "source.read": "healthy",
    "source.webhook": "healthy",
    "registry.pull": "degraded"
  }
}

Agents and UI must be able to tell:

• configured
• verified
• degraded
• expired/revoked
• missing scope
• unavailable

Track 3 — Daytona rebuild

Treat the current Daytona connector as unproven. Rebuild around one acceptance flow:

1. Select an enrolled deployment with an exact repository + revision.
2. Create isolated sandbox.
3. Clone/read the exact revision.
4. reproduce a named failure or run a named validation command.
5. apply a candidate patch only in sandbox.
6. run baseline and candidate verification against the same revision.
7. return structured evidence.
8. cleanup the sandbox under a deadline even on failure/cancellation.

"No Daytona configured" and "sandbox could not run" must never be represented as successful reproduction or validation.

Agent-native outcome

Connecting GitHub should expand GC's capability graph with source/registry tools.
Connecting Daytona should expand it with sandbox/reproduction/repair-validation tools.

This issue should be resumed after the scoped MCP/OAuth + durable operation milestone is proven end-to-end.

[teckedd-code2save]

Connector rebuild implementation is now live in production.

Landed in #91 / 091407f

Capability health contract

Connectors no longer collapse everything into a green "connected" badge.

Statuses:

• healthy
• unverified
• degraded
• missing_scope
• revoked
• unavailable
• not_configured

GitHub capabilities now report independently:

• GitHub App installation
• repository read
• repair PR write permission
• signed webhook path
• deployment repository identity
• GHCR package pull

Daytona capabilities report independently:

• API
• sandbox lifecycle
• exact-revision repository reproduction

Credential presence/configuration is no longer treated as health.

GitHub/repository identity

• repository discovery prefers installed GitHub App scope and includes private repos
• validation uses short-lived installation tokens
• if the App exists but a repo is outside the grant, GC reports "not granted" rather than silently falling back to unauthenticated public GitHub
• explicit deployment -> repository links added
• explicit links survive sync and cannot be replaced by URL inference
• Deployment Source now offers installation-backed repo selection
• manual URL remains fallback
• GHCR health reauthenticates and probes actual image access when possible

Daytona lifecycle

Deep verification now creates an ephemeral sandbox, executes a command, and deletes it. Only then can sandbox.lifecycle become healthy.

Production rollout passed, container healthy, public/MCP smokes passed.

Landed in #92 / 1d6ae9f

Added the exact workflow Daytona must prove before repository reproduction becomes healthy:

1. choose an explicitly/inferred linked deployment repository
2. require an exact deployed SHA
3. require a bounded validation command
4. create Daytona sandbox
5. clone repository (using short-lived GitHub App credential when private)
6. prove git rev-parse HEAD equals the deployed revision
7. run the validation command
8. delete/clean up sandbox
9. record only verification metadata

Added Connectors UI acceptance panel showing repository, link source, branch, exact revision, blockers, validation command, revision proof, provider and cleanup evidence.

sandbox.repository_clone remains unverified until a real acceptance run succeeds. This is intentional.

Production rollout for #92 also passed:

• container healthy
• public smoke passed
• MCP discovery smoke passed

Remaining live acceptance before closing #86

Run the new Connectors capability verification on the production instance:

1. Verify GitHub and inspect any degraded/missing-scope capability.
2. Explicitly link at least one real deployment to its installation repository.
3. Verify Daytona API + sandbox lifecycle.
4. Run the Daytona exact-revision acceptance against that deployment.
5. Confirm sandbox.repository_clone becomes healthy and evidence shows cleanup.

If Daytona fails, keep this issue open with the exact capability failure/remediation instead of patching around it.