Replace Makefile with Taskfile.yml and move all generation-related logic there

[denik]

Each task describes inputs (sources) and outputs as precise as possible.

The tasks mostly match what we had in Makefile but slightly more consistent approach:

• All go related tasks (tidy, lint, test) now have 3 subtasks for each submodule (root, tools, codegen) which are aggregated into main one. Previously we did not run tests & linters for tools and codegen modules.
• The targets that use lintdiff.py to do incremental run have -q suffix (old fmtfull -> new fmt, old fmt -> new fmt-q).
• generate:genkit is task that runs genkit + follow ups. “generate” is aggregate over all generation work.

This also consolidates all knowledge about generation in one place:

• tools/post-process.sh is removed, the followup commands are now part of generate:genkit task
• testmask no longer contains of dependencies of CI targets, it reads those from Taskfile.yml

The runner (go-task) is packaged as a go tool, no installation need. Shortcut ./task is available to run it. Makefile is temporarily a wrapper that calls ./task.

This enables caching - go-task will only re-run if sources changed. This helps when checking after agent work - if they did run linters / tests already, then running ./task is very quick.

~/work/cli-trees/task-file % time ./task
…
./task 612.63s user 310.22s system 726% cpu 2:06.95 total

~/work/cli-trees/task-file % time ./task
…
./task 2.43s user 10.58s system 133% cpu 9.727 total

Additionally, all golangci-lint tasks are fixed to use per-worktree & per-submodule tmp directory, which enables parallel runs within worktree and across worktrees.

[janniklasrose]

Let's add a task that parses Taskfile.yml to auto-gen this?

[denik]

this could be a follow up

[janniklasrose]

cating two JSON doesn't create a JSON. Better to use jq here (ditto for others)

[denik]

these are json-lines files

[janniklasrose]

should we use .jsonl then?

[denik]

we could rename, but out of scope there (and might need updating other places like deco repo)

[janniklasrose]

can we reference ws-fix task?

[denik]

yes, 4d19c6b

[janniklasrose]

should we use .jsonl then?

[simonfaltum]

Deep review (Isaac + Cursor, 2-round swarm)

Verdict: Not ready yet

Summary: 2 Critical | 9 Major | 2 Gap (Major) | 3 Nit | 4 Suggestion

Two independent reviewers (Isaac and Cursor) produced findings in parallel, then cross-reviewed each other's work, verifying claims against the code before agreeing / disagreeing. Inline comments follow below on specific lines. A few points that don't map cleanly to a single line:

Themes

1. Makefile wrapper is lossy. Plain make now errors (.DEFAULT is a catch-all, not a default goal), and make wsfix routes to a non-existent task (renamed to ws-fix). Either commit to a proper compat shim or drop the wrapper.
2. Windows CI path is broken. ./task is a POSIX shell script; the Windows matrix legs in push.yml don't set shell: bash and default to pwsh. On main today these call make (an .exe).
3. CI trigger graph is self-blind. tools/testmask only treats go.mod / go.sum / setup-build-environment/ as "common trigger" patterns. Changes to Taskfile.yml, the task launcher, or tools/testmask/** itself fall through to test only, skipping specialized jobs (test-exp-aitools, test-exp-ssh, test-pipelines) precisely when their trigger or definition changed. Ironically this very PR would skip its own specialized tests if landed as-is.
4. Similarly for python CI: python_push.yml still filters only on paths: python/** but the pydabs-* task bodies now live in root Taskfile.yml.
5. generate-genkit shell rewrite subtly changes semantics. The old Makefile A && B || C && D always ran D (the git checkout). The new grouped A && B || (C && D) skips D when the SHA is already local — so genkit can build from whatever revision the user has checked out. Minimal shell repro confirmed.
6. default / full dev loops mutate goldens. They invoke test-update, not test. Bare ./task can silently bless acceptance-output regressions.
7. Cache source-list patterns are often wrong: ROOT_LINT_SOURCES omits root go.mod/go.sum; pydabs-codegen has overlapping sources: and generates:; generate-genkit sources miss go.mod/go.sum that its embedded consistency assertion reads.

Findings dropped on cross-review (for transparency)

• ./task lint dropping --timeout=15m — verified: golangci-lint v2.5.0's --timeout is now "Disabled by default," so no regression.
• generate-refschema losing the old - ignore-errors prefix — verified: libs/testdiff's -update mode overwrites goldens on mismatch rather than failing, so the - was masking real errors, not providing needed resilience.
• ./task --force generate-schema in CI — correct pattern for generator && git diff --exit-code verification jobs; cache hits would make the check a no-op.
• make VAR=VAL dropping variables — GNU make does forward command-line variables to the delegated child; the issue is only the "no default goal" + "ws-fix rename" points.

Full synthesis: see detailed inline comments below.

[simonfaltum]

[Critical] Windows CI jobs call a POSIX-only launcher

./task is #!/bin/sh, but .github/workflows/push.yml Windows matrix jobs (test, test-exp-ssh, test-pipelines) invoke ./task … directly. On GitHub Actions, Windows run: steps default to pwsh (no workflow-level defaults.run.shell: bash, and only one per-step shell: bash exists in push.yml — line 153, the git diff step). pwsh can't invoke an extensionless shebang script.

On main today these steps call make (a native .exe resolvable under pwsh), so this is a genuine regression. Note: the composite setup-build-environment/action.yml:41-42 does set shell: bash for ./task install-pythons — the author knew the issue at that site but missed the job-level call sites.

Suggested fix: add a task.cmd / PowerShell wrapper next to task, OR add shell: bash to every Windows run: ./task … step, OR set defaults.run.shell: bash at the job level for Windows matrix legs.

Found by: Cursor, Confirmed by: Isaac

[denik]

Windows CI tests did pass on the PR though.

[simonfaltum]

[Critical] generate-genkit can build from the wrong universe revision

The old Makefile pattern A && B || C && D always ran D (the git checkout) regardless of whether the SHA was already local. The new grouped form is A && B || (C && D), which skips D when git cat-file -e succeeds. Consequence: if the requested OpenAPI SHA already exists in the local universe clone but isn't currently checked out, the task skips the checkout and builds genkit against whatever revision the user had checked out previously.

Minimal sh repro (verified):

• Old true && true || true && echo X → prints X.
• New true && true || (true && echo X) → does NOT print X.

This is a silent generator correctness bug — output diverges from .codegen/_openapi_sha.

Suggested fix: use explicit control flow so the checkout is unconditional after the existence check:

if ! git cat-file -e $(cat .../_openapi_sha) 2>/dev/null; then
    git fetch --filter=blob:none origin master
fi
git checkout $(cat .../_openapi_sha)

Found by: Cursor, Confirmed by: Isaac (with repro)

[simonfaltum]

[Major] Makefile compatibility wrapper is not actually backwards-compatible

Two separate breaks, both verified on the PR branch:

1. make with no target now fails: make: *** No targets. Stop. GNU .DEFAULT is a catch-all for named unmatched targets; it is not a default goal. The old Makefile had default: checks fmt lint.
2. make wsfix forwards to ./task wsfix, but the task was renamed to ws-fix. So make wsfix now errors: task: Task "wsfix" does not exist. Did you mean "ws-fix"? → make: *** [wsfix] Error 200. wsfix appears in the workdir CLAUDE.md and was called directly by the now-deleted tools/post-generate.sh. No migration alias exists.

(Cross-review note: Isaac's original R1 also claimed make VAR=VAL target drops variables; Cursor verified this part was wrong — GNU make does forward command-line variables to delegated children. The issue is just .DEFAULT vs default goal and the wsfix rename.)

Suggested fix: either (a) add .DEFAULT_GOAL := default + a default: ; @./task rule and keep aliases for renamed legacy targets (wsfix: ; @./task ws-fix), or (b) delete the Makefile and let make's own error point users to ./task. The current half-wrapper is the worst of both.

Found by: Isaac + Cursor (both)

[simonfaltum]

[Major] CI error message tells developers to run a task that does not exist

This error message says Run './task generate-out-test-toml' to update., but no such task exists in Taskfile.yml. The old main:Makefile had it (go test ./acceptance -run '^TestAccept$$' -only-out-test-toml); it was dropped in the migration.

Verified by running ./task generate-out-test-toml on the PR branch: it exits 200 with Task does not exist. Developers who hit this CI failure will follow the message into a second error.

(Also: .agent/rules/auto-generated-files.md on main mentions make generate-out-test-toml; that would route through .DEFAULT and hit the same dead end.)

Suggested fix: port the generate-out-test-toml target from the old Makefile into Taskfile.yml (it's a one-line go test invocation), and update agent docs if they still reference the old command.

Found by: Isaac (cross-review, R2)

[simonfaltum]

[Major] default / full dev loops rewrite acceptance goldens instead of verifying them

Both default ("Quick dev loop") and full invoke test-update rather than test. In -update mode, libs/testdiff/golden.go:45-50 overwrites expected files on mismatch instead of failing.

So a developer running bare ./task (the default target) can silently bless acceptance-output regressions. default is the implicit entrypoint for agent workflows — it needs to be verification-only.

Suggested fix: have default / full run test (verification), not test-update (mutation). If a "regen then verify" loop is useful, make it an explicitly named mutating task like update.

Found by: Cursor (cross-review, R2)

[simonfaltum]

[Nit] /tmp/ (pre-existing) and /.tmp/ (new) have different semantics

/tmp/ (line 63, pre-existing) is developer scratch; /.tmp/ (this line, new) is the per-module golangci-lint TMPDIR root configured in Taskfile.yml. Readers can't tell them apart from the current comment (line 61: # Local development notes, tmp).

Suggested fix: add an explanatory comment next to /.tmp/, e.g. # Taskfile cache for per-module golangci-lint TMPDIR (see Taskfile.yml).

Found by: Isaac (R1)

[simonfaltum]

[Nit] fmt-q-go shares *FMT_GO_SOURCES with fmt-go; identical checksums mean fmt-q-go gets cached as "done" after fmt-go

Both tasks declare identical sources: via the same anchor. Once fmt-go has run, go-task's checksum cache will treat fmt-q-go as already up-to-date with the same checksum, even though the two have different semantics (full fmt vs diff-only fmt).

Low impact, but a user who runs fmt-go and then explicitly asks for fmt-q-go gets a no-op.

Suggested fix: either (a) give fmt-q-go a distinguishing source (e.g. .git/HEAD so branch changes invalidate it), or (b) set method: none on fmt-q-go so it always runs (it's cheap when nothing changed).

Found by: Isaac (R1), Confirmed by: Cursor (R2)

[simonfaltum]

[Nit] NESTED_MODULES is prefix-based but looks explicit

NESTED_MODULES = ("bundle/internal/tf/codegen", "tools") — the membership check at line 65 matches path == m or path.startswith(m + "/"), so it correctly catches tools/task/go.mod via the tools/ prefix. That's four real nested modules covered by two entries.

A future contributor adding a module outside these two prefixes will silently miss it; one adding a sibling to tools/task/ might not realize the prefix semantics and add a redundant entry.

Suggested fix: add a comment documenting the prefix-based semantics, or replace with a dynamic walker that discovers go.mod files (excluding the root).

Found by: Isaac (cross-review, R2)

[simonfaltum]

[Suggestion] generate-schema-docs silently loses sinceVersion annotations on tag-less checkouts

The old tools/post-generate.sh (deleted in this PR) ran git fetch origin 'refs/tags/v*:refs/tags/v*' before invoking schema-for-docs. bundle/internal/schema/since_version.go:78-99 shells out to git tag --list 'v*' and git show <tag>:… to compute sinceVersion fields.

With no tags present (e.g., a fresh shallow clone), getVersionTags returns empty and the generated jsonschema_for_docs.json silently drops sinceVersion fields — no error.

CI is unaffected because the validate-generated check runs ./task --force generate-schema without --docs, but local ./task generate now produces subtly different jsonschema_for_docs.json output on tag-less checkouts.

Suggested fix: either add git fetch --tags as a pre-step in generate-schema-docs, or have computeSinceVersions log a warning when it sees zero tags but nonzero commit history.

Found by: Isaac (cross-review, R2)

[simonfaltum]

[Suggestion] Concurrent ./task test* runs share worktree-level output files

test-unit cats three per-module JSON files into test-output-unit.json (line 323); test then cats test-output-unit.json and test-output-acc.json into test-output.json (line 311). The three specialized test tasks (test-exp-aitools, test-exp-ssh, test-pipelines) all also end with cat ... > test-output.json.

Two agents running ./task test* (or mixes of them) in the same worktree will interleave writes — gotestsum --jsonfile opens-and-truncates. Cursor correctly noted origin/main already had this race via make test, so it's pre-existing, not a new Taskfile regression.

Still worth improving given the PR's stated motivation ("faster verification after agent work") specifically incentivizes concurrent invocations.

Suggested fix: write per-run JSON into .task/run-<id>/test-output-*.json and have the aggregator cat from there. Or at minimum, document that concurrent test* invocations in the same worktree are unsupported.

Found by: Isaac (R1), scope-corrected by Cursor (R2)