When I push things still go via SSH to GitHub

I'd prefer pushes (of checkpoints as well as my other git operations) all use entire:// push-through mirrors. Figure out from @.entire/settings.json why this isn't the case.

Found it: Your settings force checkpoints onto GitHub, and the resolver can't produce entire:// URLs at all.

Bottom line: Your normal pushes already go through the mirror (origin is entire://aws-ap-southeast-2.entire.io/gh/entireio/cli). The SSH-to-GitHub traffic is the checkpoint machinery, caused by checkpoint_remote: {"provider": "github", ...} in .entire/settings.json:5-8 — and there is currently no way to configure a checkpoint remote that routes via entire://. It's a feature gap, not a settings mistake.

The exact chain:

• At pre-push, resolvePushSettings calls remote.PushURL(ctx, "origin") (cmd/entire/cli/strategy/checkpoint_remote.go:70).
• PushURL tries to derive the checkpoint URL from origin's protocol, but entire:// is not a "derivable" transport — only SSH and HTTPS are (cmd/entire/cli/checkpoint/remote/util.go:284-286, util.go:288-302).
• So it falls into resolveProviderCheckpointURL (util.go:226), which maps provider github → host github.com (util.go:421-430) and picks a transport by precedence (util.go:340-361): token → reuse an existing remote's scheme for that host → default SSH.
• Your git config has URL-named promisor remotes left by filtered_fetches (remote.git@github.com:entireio/cli-checkpoints.git.promisor true etc.), so step 2 matches SSH — and even without them, step 3 defaults to SSH anyway. Result: checkpoints push/fetch over git@github.com:entireio/cli-checkpoints.git.
• GetCheckpointRemote (cmd/entire/cli/settings/settings.go:1399) only accepts {provider, repo} with provider ∈ {github, gitlab} — no raw-URL form, no "entire" provider. So no settings.json edit can route the checkpoint repo through the mirror today.

Your options:

1. Delete the checkpoint_remote block — checkpoints then push to origin, i.e. through the entire:// mirror, but they land on entire/checkpoints/v1 of entireio/cli itself instead of the separate cli-checkpoints repo. Tradeoff: you lose the separate-repo isolation, gain full mirror routing immediately.
2. Keep the separate repo, add the feature — teach checkpoint_remote to accept an entire:// target (e.g. {\"url\": \"entire://<cluster>/gh/entireio/cli-checkpoints\"}), plus create a push-through mirror for cli-checkpoints. That's a CLI change in checkpoint/remote/util.go + settings.go.

Side observations: the remote.entire://eukanuba.partial.to/... promisor entry is a stale leftover from an old mirror host, and remote.origin.entiredb-original-url confirms origin was already migrated off SSH — so the checkpoint path is the only SSH user left in this repo's config.

Want me to implement option 2 (an entire://-capable checkpoint remote), or just flip you to option 1?

Yes, we need to add the feature. Make it so our tool understands how to push to entire://, then configure the checkpoint remote to use that. The cluster we'll use is entire://aws-ap-southeast-2.entire.io.

Done — committed as 855b8cdab on swirling-doodling-waffle (not pushed, per your rules).

Bottom line: Checkpoints now follow origin through the mirror: with your existing settings, the checkpoint URL resolves to entire://aws-ap-southeast-2.entire.io/gh/entireio/cli-checkpoints — no settings.json edit needed, and I confirmed that mirror is live.

What changed:

• deriveCheckpointURLFromInfo (cmd/entire/cli/checkpoint/remote/util.go:302) gained an entire case: keep the cluster host and forge, swap in the checkpoint repo. Guarded so the forge must map to the configured provider (gh ↔ github) — a forge-mismatched mirror or file:// origin still falls back to provider-host routing, and fork-owner detection still applies.
• ENTIRE_CHECKPOINT_TOKEN still forces https://github.com/... (CI has no helper auth; the token can't ride through entire://).
• Flipped TestPushURL_EntireOriginReusesProviderRemoteScheme (which pinned the old "route to GitHub" behavior from regression #1279) into TestPushURL_EntireOriginDerivesMirrorURL, reproducing your exact setup — entire:// origin on aws-ap-southeast-2 plus leftover git@github.com promisor remotes — and asserting they no longer divert checkpoints off the mirror. Updated the test-plan doc rows that documented #1279.

Why no config change:

The resolver's design derives transport from the push remote, so the cluster is inherited from origin — which is already entire://aws-ap-southeast-2.entire.io/gh/entireio/cli. This also keeps the committed settings.json portable: teammates on SSH origins keep SSH, anyone on a mirror uses their mirror, all landing in the same cli-checkpoints repo. Tradeoff: if you ever want the cluster pinned independent of origin, that needs an explicit URL-form config we didn't add.

Verified:

mise run fmt && mise run lint clean (diff checked after), targeted package tests pass (checkpoint/..., gitremote, settings, strategy), and git ls-remote entire://aws-ap-southeast-2.entire.io/gh/entireio/cli-checkpoints returns HEAD plus existing checkpoint refs. Full suite left to CI per your preference. Your next real push's pre-push hook is the live confirmation — the checkpoint leg should dial the cluster instead of opening an SSH connection to github.com.

One inert leftover: the shared .git/config still has git@github.com:... promisor entries from old filtered fetches. They're harmless (fetches will now create an entire:// promisor entry), and I left the shared config untouched from this worktree.

855b8cd Route checkpoints through entire:// push-through mirrors

When origin (or the push remote) is an entire:// mirror URL and its forge matches the configured checkpoint_remote provider (gh <-> github), derive the checkpoint URL on the same cluster (entire:////) instead of falling back to direct SSH/HTTPS against the provider host. The provider-host fallback remains for file:// and forge-mismatched mirrors, and ENTIRE_CHECKPOINT_TOKEN still forces provider HTTPS since the token cannot ride through the helper.

Co-Authored-By: Claude Fable 5 noreply@anthropic.com Entire-Checkpoint: 01KXCGE6FQGMQB906H5TAVVRZ9+100/-35