turbo-editors/turbo-go · 2026-09-01-tickets-9-to-14.md

⑂ v1.0.2

2026-09-01-tickets-9-to-14.md · 34 lines · 1.9 KBmarkdown    Blame HistoryRaw
   1# Handoff — 2026-09-01 — tickets 9 to 14
5Done, on the branch `feature/menu-theme-and-settings`. Nothing is committed.
7Only **ticket 9** is this repository's: the settings template now writes `autosave = true`. The other five are turbo-core's and reach Turbo Go through the library.
9Suite green, quality gate **PASS 0/0/0**, complexity unchanged. Documentation updated in EN and FR: the settings, menus, tools and snippets references, `configure-a-project.md`, and a new section in `run-the-tests.md` on testing against an unreleased turbo-core.
11**This branch builds as it stands**, against the published `turbo-core v0.2.0`. That is deliberate and unlike the last two releases, which left the editors unbuildable until the library was published.
13## In flight
15Nothing half-done.
17## Next steps
191. Review and commit, merge to `main`.
202. After **turbo-core v0.3.0** is published — see turbo-core's handoff of the same date:
22   go get codeberg.org/turbo-editors/turbo-core@v0.3.0
23   go mod tidy && make check
25   That is when the five library-side tickets become visible here.
27## Open questions / blockers
31## Watch out for
33- **`settings.Default()` must stay `autosave: false`.** Only the template turns it on. The library default is what applies to a project with no settings file, and the editor writing to disk in a directory somebody merely started it in is a much larger claim than the ticket asked for. `TestAProjectWithNoSettingsFileStillDoesNotAutosave` holds that line.
34- **To work against a turbo-core checkout beside this one, use `go work init . ../turbo-core`, not a `replace`.** It changes no tracked file, so there is nothing to forget before committing, and `go.work` is gitignored. Verify with `go list -f '{{.Dir}}' codeberg.org/turbo-editors/turbo-core/app` — if it answers a `pkg/mod` path you are testing the published library and everything will still pass.

📦 Turbo Go 3d7798b k33g 9h ago	1	# Handoff — 2026-09-01 — tickets 9 to 14
	2
	3	## State
	4
	5	Done, on the branch `feature/menu-theme-and-settings`. Nothing is committed.
	6
	7	Only ticket 9 is this repository's: the settings template now writes `autosave = true`. The other five are turbo-core's and reach Turbo Go through the library.
	8
	9	Suite green, quality gate PASS 0/0/0, complexity unchanged. Documentation updated in EN and FR: the settings, menus, tools and snippets references, `configure-a-project.md`, and a new section in `run-the-tests.md` on testing against an unreleased turbo-core.
	10
	11	This branch builds as it stands, against the published `turbo-core v0.2.0`. That is deliberate and unlike the last two releases, which left the editors unbuildable until the library was published.
	12
	13	## In flight
	14
	15	Nothing half-done.
	16
	17	## Next steps
	18
	19	1. Review and commit, merge to `main`.
	20	2. After turbo-core v0.3.0 is published — see turbo-core's handoff of the same date:
	21	```sh
	22	go get codeberg.org/turbo-editors/turbo-core@v0.3.0
	23	go mod tidy && make check
	24	```
	25	That is when the five library-side tickets become visible here.
	26
	27	## Open questions / blockers
	28
	29	- None.
	30
	31	## Watch out for
	32
	33	- `settings.Default()` must stay `autosave: false`. Only the template turns it on. The library default is what applies to a project with no settings file, and the editor writing to disk in a directory somebody merely started it in is a much larger claim than the ticket asked for. `TestAProjectWithNoSettingsFileStillDoesNotAutosave` holds that line.
	34	- To work against a turbo-core checkout beside this one, use `go work init . ../turbo-core`, not a `replace`. It changes no tracked file, so there is nothing to forget before committing, and `go.work` is gitignored. Verify with `go list -f '{{.Dir}}' codeberg.org/turbo-editors/turbo-core/app` — if it answers a `pkg/mod` path you are testing the published library and everything will still pass.