chore(todo): the installer also leaves the dotfiles clone unable to pushHEADmain

Same two lines as the shallow-clone defect, found while pushing today. The dotfiles remote defaults to the public read-only endpoint, so a machine the installer built can fetch but never push. My other machine uses the ssh form, so the rebuilt one was the odd one out purely because the installer made it.

That half is a decision rather than a fix, so the task loses its solo tag. The read-only default is right for anyone else installing this, who has no key on the server, and wrong for my own machines. The override already exists, so the only question is where my value lives.

1 files changed, 25 insertions, 5 deletions

diff --git a/todo.org b/todo.org
index 1ec7cf1..32eb9a2 100644
--- a/todo.org
+++ b/todo.org
@@ -236,7 +236,7 @@ unless you look) x rare edge case (one machine, specific conditions) = P2 =
 [#B]... except that this is a live, ongoing drain on a travelling machine
 rather than a latent defect, so it takes [#A] until the machine is back to
 normal. Re-grade to [#B] once resolved and the question is only prevention.
-** TODO [#A] The installer shallow-clones the two repos I develop in :bug:velox:solo:
+** TODO [#A] The installer clones my two working repos shallow and read-only :bug:velox:
 :PROPERTIES:
 :CREATED: [2026-08-17 Mon]
 :LAST_REVIEWED: 2026-08-17
@@ -263,16 +263,36 @@ gets =--depth 1= and org does not. The AUR build clones (=archsetup:855=,
 =:1673=, =:1677=) are correctly shallow and stay that way. Only the two
 user-repo sites change.
 
-Repair on a machine already built: =git fetch --unshallow= in each repo.
+*Second defect, same two lines, found 2026-08-17 while pushing:* the dotfiles
+clone could not push at all. =archsetup:245= defaults =dotfiles_repo= to
+=https://git.cjennings.net/dotfiles.git=, the public read-only endpoint, so
+=git push= returned 403. Ratio uses =git@cjennings.net:dotfiles.git= and
+archsetup's own clone uses the matching ssh form, so velox was the odd one out
+purely because it was the machine rebuilt by the installer. Repointed velox's
+remote and pushed.
+
+That half needs a decision rather than a fix, which is why this task is no
+longer =:solo:=. The https default is *correct for a stranger* installing
+archsetup, who has no ssh key on the server, and this repo is being prepared
+for public release. It is wrong for my own machines, which need to push. The
+override already exists (=DOTFILES_REPO=, documented in
+=archsetup.conf.example=), so the question is only where my personal value
+lives: a config the personal ISO bakes in, a post-install step, or a detection
+that prefers ssh when a key is present. Craig's call.
+
+Repair on a machine already built: =git fetch --unshallow= in each repo, and
+=git remote set-url origin git@cjennings.net:<repo>.git= for dotfiles.
 
 Grading: Major severity (two working repos silently missing their history on
 the machine I develop on, and it returns confidently wrong answers to history
 questions rather than failing) x every user every time (every fresh install,
 both daily drivers) = P1 = [#A].
 
-:solo: — the change is two lines plus tests in the existing
-=tests/installer-steps/= shape, and it is verifiable locally by asserting the
-clone command carries no =--depth= for these two repos.
+Not :solo:. The depth half is (two lines plus tests in the existing
+=tests/installer-steps/= shape, verifiable by asserting the clone command
+carries no =--depth= for these two repos). The remote-URL half needs the
+decision above, so the task as a whole waits on it. Split it in two if the
+depth fix is wanted sooner.
 ** TODO [#B] post-rebuild-check needs a reference-host mode :feature:velox:solo:
 :PROPERTIES:
 :CREATED: [2026-08-17 Mon]