turbo-editors/turbo-gopublic Fork 0
v1.0.2
Commits
Clone
git clone https://git.rickub.com/turbo-editors/turbo-go.git
git clone ssh://git@rickub.com/turbo-editors/turbo-go.git

Host key fingerprint (ed25519): SHA256:iycHnxEyq0Q7uyVpB7JlznP0G7JrTPXLYRcAU5CSLhc — verify it before your first connect.

📦 Turbo Go 3d7798b · on v1.0.2 · k33g · 7h ago
2026-09-01-tool-parameters.md · 33 lines · 1.8 KBmarkdown
Blame HistoryOpen raw

Handoff — 2026-09-01 — Tool parameters

State

The feature itself is turbo-core's; see its handoff of the same date. What changed here is small and green:

  • the starter tools file now teaches {{label}} and {{label...}} in its comments;
  • one installer test that asserted before checking it was in a git checkout.

Whole suite green, quality gate PASS at 0/0/0.

Committed and released as v0.2.2 at d64410c, which is exactly HEAD. Working tree clean, on main. The dependency is the published turbo-core v0.1.0, with no active replace.

In flight

Nothing.

Next steps

  1. Try a parameterised tool in real work. Nobody has, and the first hour of it will find something.
  2. Two lines of tidying in go.mod, whenever something else takes you there: the commented-out replace block, whose text is now false, and the missing trailing newline.

Open questions / blockers

None.

Watch out for

  • turbo-core v0.1.0 does not contain its own 02-release.publish.sh. That library's tag was cut one commit early. It changes nothing here, but do not be surprised by the gap when reading its release page.

  • The placeholder examples are in comments, not tools. TestTheCreatedToolsFileStillLoadsWithItsPlaceholderExamples exists because the loader reads the whole file: if one of those examples ever became a real [[tool]], Create tools file would start asking everybody for a value.

  • No backticks in the templates. They are raw Go strings, so a backtick ends the literal. The first draft of the comment block used them for awk '{print $1}' and would not compile; the prose says it without them.

  • The installer test skips outside a git checkout, because unknown is then the right answer. If you see it skipped in CI, check whether the checkout is shallow rather than assuming the test is broken.

 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
27
28
29
30
31
32
33
# Handoff — 2026-09-01 — Tool parameters

## State

The feature itself is turbo-core's; see its handoff of the same date. What changed here is small and green:

- the starter tools file now teaches `{{label}}` and `{{label...}}` in its comments;
- one installer test that asserted before checking it was in a git checkout.

Whole suite green, quality gate PASS at 0/0/0.

**Committed and released as v0.2.2** at `d64410c`, which is exactly HEAD. Working tree clean, on `main`. The dependency is the published `turbo-core v0.1.0`, with no active `replace`.

## In flight

Nothing.

## Next steps

1. **Try a parameterised tool in real work.** Nobody has, and the first hour of it will find something.
2. **Two lines of tidying in `go.mod`**, whenever something else takes you there: the commented-out replace block, whose text is now false, and the missing trailing newline.

## Open questions / blockers

None.

## Watch out for

- **turbo-core v0.1.0 does not contain its own `02-release.publish.sh`.** That library's tag was cut one commit early. It changes nothing here, but do not be surprised by the gap when reading its release page.

- **The placeholder examples are in comments, not tools.** `TestTheCreatedToolsFileStillLoadsWithItsPlaceholderExamples` exists because the loader reads the whole file: if one of those examples ever became a real `[[tool]]`, `Create tools file` would start asking everybody for a value.
- **No backticks in the templates.** They are raw Go strings, so a backtick ends the literal. The first draft of the comment block used them for `awk '{print $1}'` and would not compile; the prose says it without them.
- **The installer test skips outside a git checkout**, because `unknown` is then the right answer. If you see it skipped in CI, check whether the checkout is shallow rather than assuming the test is broken.