Taskfile leaks source project name (hostexecutor); scaffold uses stale hostname #5

Closed
opened 2026-06-22 13:58:42 +00:00 by mathias · 1 comment
Owner

Problem

Two leaked-identity bugs in the web template, both from the source project (hostexecutor) it was extracted from. The placeholder substitution that new-project.sh applies covers most files but the Taskfile was never parameterised.

Bug 1 — Taskfile hard-codes hostexecutor instead of __PROJECT_NAME__

Taskfile.yml build and run reference bin/hostexecutor and ./cmd/hostexecutor:

build: cmds: [go build -o bin/hostexecutor ./cmd/hostexecutor]
run:   deps: [build]; cmds: [./bin/hostexecutor]

new-project.sh renames cmd/__PROJECT_NAME__cmd/$NAME and seds __PROJECT_NAME__ everywhere — but the Taskfile says the literal string hostexecutor, which the sed never touches. Result: every scaffolded web project has a Taskfile pointing at a ./cmd/hostexecutor directory that no longer exists. task build/task run break immediately post-scaffold.

The agent template (template-go-agent) does this correctly with __PROJECT_NAME__ — copy that pattern.

Bug 2 — new-project.sh uses the stale gitea.d-ma.be hostname (latent)

scripts/new-project.sh (in local-dev) downloads this template via:

curl -sL --fail "http://gitea.d-ma.be/mathias/template-go-web/archive/main.tar.gz"

Per ADR-0004 the canonical host is git.d-ma.be; gitea.d-ma.be is the cooldown alias. The alias is still on as of 2026-06-22, so this is latent — not yet breaking. The moment the alias is removed from ingress/NPM/Kyverno/containerd, task new-project breaks entirely. Also it's plain http://.

NOTE: this bug lives in local-dev/scripts/new-project.sh, not in this repo. Cross-filed here because it's the same scaffolding fault surface; the fix may land in local-dev. See also the local-dev issue.

Spec

intent:
  goal: make scaffolded web projects build correctly and survive the hostname cutover
  inputs: template-go-web/Taskfile.yml, local-dev/scripts/new-project.sh
  outputs: parameterised_taskfile, canonical_hostname
accept:
  - Taskfile build/run target __PROJECT_NAME__, not the literal hostexecutor
  - a freshly scaffolded web project runs `task build` and `task run` with no manual edit
  - new-project.sh fetches over https from git.d-ma.be
  - no reference to gitea.d-ma.be remains in the scaffold path

Constraints

  • All-Go / template parity: match the __PROJECT_NAME__ convention already in template-go-agent.
  • Coordinate the hostname change with the broader gitea.d-ma.be alias removal — grep the whole scaffold path, don't fix this one curl in isolation.

Handoff

Planning here; implementation on koala. PR back to main, reference this issue.

## Problem Two leaked-identity bugs in the web template, both from the source project (`hostexecutor`) it was extracted from. The placeholder substitution that `new-project.sh` applies covers most files but the Taskfile was never parameterised. ### Bug 1 — Taskfile hard-codes `hostexecutor` instead of `__PROJECT_NAME__` `Taskfile.yml` `build` and `run` reference `bin/hostexecutor` and `./cmd/hostexecutor`: ``` build: cmds: [go build -o bin/hostexecutor ./cmd/hostexecutor] run: deps: [build]; cmds: [./bin/hostexecutor] ``` `new-project.sh` renames `cmd/__PROJECT_NAME__` → `cmd/$NAME` and seds `__PROJECT_NAME__` everywhere — but the Taskfile says the literal string `hostexecutor`, which the sed never touches. Result: **every scaffolded web project has a Taskfile pointing at a `./cmd/hostexecutor` directory that no longer exists.** `task build`/`task run` break immediately post-scaffold. The agent template (`template-go-agent`) does this correctly with `__PROJECT_NAME__` — copy that pattern. ### Bug 2 — `new-project.sh` uses the stale `gitea.d-ma.be` hostname (latent) `scripts/new-project.sh` (in `local-dev`) downloads this template via: ``` curl -sL --fail "http://gitea.d-ma.be/mathias/template-go-web/archive/main.tar.gz" ``` Per ADR-0004 the canonical host is `git.d-ma.be`; `gitea.d-ma.be` is the cooldown alias. **The alias is still on as of 2026-06-22, so this is latent — not yet breaking.** The moment the alias is removed from ingress/NPM/Kyverno/containerd, `task new-project` breaks entirely. Also it's plain `http://`. > NOTE: this bug lives in `local-dev/scripts/new-project.sh`, not in this repo. Cross-filed here because it's the same scaffolding fault surface; the fix may land in `local-dev`. See also the `local-dev` issue. ## Spec ``` intent: goal: make scaffolded web projects build correctly and survive the hostname cutover inputs: template-go-web/Taskfile.yml, local-dev/scripts/new-project.sh outputs: parameterised_taskfile, canonical_hostname accept: - Taskfile build/run target __PROJECT_NAME__, not the literal hostexecutor - a freshly scaffolded web project runs `task build` and `task run` with no manual edit - new-project.sh fetches over https from git.d-ma.be - no reference to gitea.d-ma.be remains in the scaffold path ``` ## Constraints - All-Go / template parity: match the `__PROJECT_NAME__` convention already in `template-go-agent`. - Coordinate the hostname change with the broader `gitea.d-ma.be` alias removal — grep the whole scaffold path, don't fix this one curl in isolation. ## Handoff Planning here; implementation on koala. PR back to `main`, reference this issue.
Author
Owner

Both bugs already fixed: Taskfile.yml on main uses __PROJECT_NAME__ placeholder (not literal hostexecutor), and new-project.sh already downloads via git.d-ma.be. Confirmed via live end-to-end scaffold test (go-web stack) — correct binary paths, module path, no leaked identity. Closing.

Both bugs already fixed: Taskfile.yml on main uses `__PROJECT_NAME__` placeholder (not literal `hostexecutor`), and `new-project.sh` already downloads via `git.d-ma.be`. Confirmed via live end-to-end scaffold test (go-web stack) — correct binary paths, module path, no leaked identity. Closing.
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mathias/template-go-web#5