Handoff — 2026-09-20 — -load-config (needs turbo-core v1.0.3)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

# Handoff — 2026-09-20 — `-load-config` (needs turbo-core v1.0.3)

## State

- `-load-config <url>` wired in `main.go`, three tests in `main_test.go`, docs EN+FR updated. Green under the umbrella `go.work` (`turbo-editors/`), which resolves turbo-core to the local checkout.
- **`go.mod` still says turbo-core v1.0.2** — `GOWORK=off make check` fails until turbo-core v1.0.3 is tagged and this is re-pinned. Even under the workspace, the two release-script tests (`TestTheTagScript…`) fail for the same reason: they build a copy of the module outside it. Everything else is green.

## Next steps

1. When turbo-core v1.0.3 is tagged: `go get rickub.com/turbo-editors/turbo-core@v1.0.3 && go mod tidy && GOWORK=off make check`.
2. Try it for real: in an empty directory, `turbo-js -load-config https://rickub.com/turbo-editors/configs/tree/main/golang-init` (the sample repository holds `.turbo-go` only — for this editor a directory with a `.turbo-js` is needed), then start `turbo-js` and check the settings took.
3. Then `./01-release.tag.sh` as usual.

## Traps

- The sample configs repository is `rickub.com/turbo-editors/configs`; its git address is `git.rickub.com`, which `configrepo` tries second. A wrong first candidate costs one `ls-remote`, not the load.
- The editor refuses when `.turbo-js` already exists (`configrepo.ErrExists`); there is deliberately no `--force`.

## Also

`release.env` is committed from now on (`!release.env` in `.gitignore`). `01-release.tag.sh` does `git add .`, so the next release commits it by itself.

## Update, end of session

turbo-core v1.0.3 is published and `go.mod` pins it (done from the host, with a commit, during the session). Step 1 of "Next steps" is done; the two release-script tests are expected green again — see the history entry for the run that confirmed it.