Derive and validate the cloud repository identity

[alexhraber]

Context

The v0.83.0 Propodus client accepts cloud.repo_id from configuration. For dogfooding, repository identity must be tied to the actual GitHub repository rather than an arbitrary string supplied by a project file.

Goal

Derive and validate the canonical repository identity used for the initial Propodus cloud call.

Scope

• Resolve the current repository’s canonical GitHub owner/name and immutable repository identity from its configured remote or an explicit authenticated resolver.
• For the initial dogfood rollout, require the repository to be DecapodLabs/decapod before selecting the cloud backend.
• Fail closed with an actionable configuration/authorization error for another repository; do not send a caller-selected repo_id to Propodus as if it were verified identity.
• Keep the resolver provider-agnostic enough for the future, but do not broaden the initial production allowlist.
• Keep fork identity distinct: a fork remains a separate solo repository and does not inherit the organization’s cloud slice.

Acceptance criteria

• The Decapod repository resolves to DecapodLabs/decapod in the dogfood fixture.
• A renamed, missing, ambiguous, or non-GitHub remote produces a clear preflight error.
• A different repository cannot accidentally address the DecapodLabs organization slice.
• The immutable repository identity is available to the Propodus request path.
• Tests cover remote parsing, canonicalization, allowlist failure, and fork separation.

[alexhraber]

Initial dogfood identity scope is the canonical organization repository DecapodLabs/decapod. A user-owned fork remains a separate solo repository and must not address the organization slice.

[alexhraber]

PR #1043 advances this boundary without changing the repository local default: cloud identity is derived from the GitHub origin, fork identities remain distinct for provider authorization, and onboarding/session payloads are typed and offline-tested. Decapod does not implement hosted authentication, authorization policy, persistence, deployment, or business logic. Live exchange and protected end-to-end proof remain follow-up work once the external contract is proven.

[alexhraber]

Status update — 2026-07-26

PR 1043 established typed origin-derived identity and fork separation. Propodus currently authorizes the initial dogfood repository through deployment policy.

Next: pass canonical immutable repository identity through the live request path; prove a different repository and fork cannot address the organization slice; and keep repository authorization server-owned. Keep open.