The Makefile diverges from our standard scripts-to-rule-them-all (STRTA) scaffold. Under STRTA, the Makefile is a set of thin shims that delegate to script/* POSIX-sh entrypoints, and CI runs script/cibuild. The living reference is the netwatch repo (Makefile + script/ + .gitea/workflows/check.yml); mirror it exactly.
Current state (nonconformance)
Makefile targets are inline recipes rather than @script/* shims: test, fmt, fmt-check, lint, check, docker, and hooks all contain inline commands.
Missing standard targets: bootstrap, setup.
No script/ directory.
.gitea/workflows/check.yml exists but runs docker build . directly instead of script/cibuild.
Definition of done
Makefile has a .PHONY declaration listing at least the nine standard targets: bootstrap, setup, test, lint, fmt, fmt-check, check, docker, hooks.
Each of those nine standard targets is a thin shim whose recipe is exactly @script/NAME (test calls @script/test, hooks calls @script/install-precommit, etc.). Repo-specific extra targets are allowed but must not replace the standard shims.
A script/ directory holds executable POSIX-sh entrypoints (#!/bin/sh, set -e) for bootstrap, setup, test, lint, fmt, fmt-check, check, docker, install-precommit, plus cibuild. The real logic currently inline in the Makefile moves into these scripts.
script/check runs the repo's full local verification (fmt-check + lint + test); script/cibuild is the CI entrypoint (typically docker build .), and the Dockerfile build runs make check so the image build fails on any check failure.
.gitea/workflows/check.yml invokes script/cibuild rather than a bare docker build ..
make check passes locally and docker build . succeeds (green) before the change lands.
The finishing commit's title must end with (closes #N) referencing this issue.
The `Makefile` diverges from our standard scripts-to-rule-them-all (STRTA) scaffold. Under STRTA, the `Makefile` is a set of thin shims that delegate to `script/*` POSIX-`sh` entrypoints, and CI runs `script/cibuild`. The living reference is the `netwatch` repo (`Makefile` + `script/` + `.gitea/workflows/check.yml`); mirror it exactly.
## Current state (nonconformance)
- `Makefile` targets are inline recipes rather than `@script/*` shims: `test`, `fmt`, `fmt-check`, `lint`, `check`, `docker`, and `hooks` all contain inline commands.
- Missing standard targets: `bootstrap`, `setup`.
- No `script/` directory.
- `.gitea/workflows/check.yml` exists but runs `docker build .` directly instead of `script/cibuild`.
## Definition of done
1. `Makefile` has a `.PHONY` declaration listing at least the nine standard targets: `bootstrap`, `setup`, `test`, `lint`, `fmt`, `fmt-check`, `check`, `docker`, `hooks`.
2. Each of those nine standard targets is a thin shim whose recipe is exactly `@script/NAME` (`test` calls `@script/test`, `hooks` calls `@script/install-precommit`, etc.). Repo-specific extra targets are allowed but must not replace the standard shims.
3. A `script/` directory holds executable POSIX-`sh` entrypoints (`#!/bin/sh`, `set -e`) for `bootstrap`, `setup`, `test`, `lint`, `fmt`, `fmt-check`, `check`, `docker`, `install-precommit`, plus `cibuild`. The real logic currently inline in the `Makefile` moves into these scripts.
4. `script/check` runs the repo's full local verification (`fmt-check` + `lint` + `test`); `script/cibuild` is the CI entrypoint (typically `docker build .`), and the `Dockerfile` build runs `make check` so the image build fails on any check failure.
5. `.gitea/workflows/check.yml` invokes `script/cibuild` rather than a bare `docker build .`.
6. `make check` passes locally and `docker build .` succeeds (green) before the change lands.
The finishing commit's title must end with ` (closes #N)` referencing this issue.
Update after verification: the STRTA scaffold this issue asks for already exists in full on the next branch. That branch's Makefile is thin @script/* shims for all nine standard targets, backed by a complete script/ set including script/cibuild; it landed there on 2026-07-07.
main is divergent by design: simplelog is post-1.0.0 (tagged 1.0.1), and under our branch convention main carries only the current released version, with next merged to main and tagged on each release. So the fix for main is not to re-implement the scaffold here — it is to release next to main.
Because that is a release/versioning call, it is yours to make:
(a) Cut a release now: merge next into main and tag a new version (1.0.2, or 1.1.0 given the new scaffolding), which lands STRTA on main and closes this issue. main is unprotected, so I can perform the merge and tag on your go-ahead.
(b) Defer: leave main as-is until the next planned simplelog release, which will carry the scaffold along automatically.
Recommendation: (a), unless you are holding simplelog's release for other pending work — in which case (b). Tell me which, and the version string for (a), and I will land it. I have stood down the redundant fixer subagent I had dispatched against main.
Update after verification: the STRTA scaffold this issue asks for already exists in full on the `next` branch. That branch's `Makefile` is thin `@script/*` shims for all nine standard targets, backed by a complete `script/` set including `script/cibuild`; it landed there on 2026-07-07.
`main` is divergent by design: simplelog is post-1.0.0 (tagged `1.0.1`), and under our branch convention `main` carries only the current released version, with `next` merged to `main` and tagged on each release. So the fix for `main` is not to re-implement the scaffold here — it is to release `next` to `main`.
Because that is a release/versioning call, it is yours to make:
- (a) Cut a release now: merge `next` into `main` and tag a new version (1.0.2, or 1.1.0 given the new scaffolding), which lands STRTA on `main` and closes this issue. `main` is unprotected, so I can perform the merge and tag on your go-ahead.
- (b) Defer: leave `main` as-is until the next planned simplelog release, which will carry the scaffold along automatically.
Recommendation: (a), unless you are holding simplelog's release for other pending work — in which case (b). Tell me which, and the version string for (a), and I will land it. I have stood down the redundant fixer subagent I had dispatched against `main`.
sneak
was assigned by clawbot2026-07-25 13:19:57 +02:00
State, 2026-10-03 12:40 UTC: queued first in this repo, no worker started (manager stood down for RAM). main and next were both green at 7f0cd5d and ac3031a.
Plan. The scaffold this issue asks for is already on next; what is missing is that next and main have diverged. main (v1.0.2, 7f0cd5d) has golangci-lint v2.12.2 with .golangci.yml and the slog attribute fix; next (ac3031a) has the script/ scaffold, the Makefile shims, the workflow running script/cibuild, and REPO_POLICIES.md. Neither contains the other. This unit brings main into next, and the scaffold reaches main when sneak merges next. That is how his "proceed with a release" ruling above gets carried out under the current branch rules.
Branch sync-main-into-next from current next. Merge origin/main into it as a real two-parent merge: no rebase, cherry-pick or squash, so that main becomes an ancestor of next and the later next-to-main merge does not conflict.
Only README.md and TODO.md conflict. Resolve both by hand and keep both sides: main's handler documentation and next's Entrypoints section; both sides' completed steps. Correct any sentence the merged tree makes false, and add nothing else. The Dockerfile merges cleanly to main's v2.12.2 lint image.
Item 4 (the Dockerfile runs make check): judgement call to keep its separate make fmt-check, make lint and make test steps. Those are the three checks script/check runs, so the image build already fails on any check failure, and a single make check step would have to change again when #20 moves the linter into its own docker build.
.golangci.yml stays unchanged. #20, #22 and #23 are separate units that start from next once this one lands.
script/cibuild must pass, with the three check steps actually executed and not served from the build cache.
The PR targets next and is titled Bring main's fixes into next (closes #16). On a passed review the manager merges it with Gitea's merge-commit style, not squash, for the ancestry reason in step 1. That deviates from the one-squash-per-issue rule; it applies only to this unit. Before pushing, the worker merges (never rebases) any newer next into the branch.
Model: opus-5-5
State, 2026-10-03 12:40 UTC: queued first in this repo, no worker started (manager stood down for RAM). `main` and `next` were both green at `7f0cd5d` and `ac3031a`.
Plan. The scaffold this issue asks for is already on `next`; what is missing is that `next` and `main` have diverged. `main` (`v1.0.2`, `7f0cd5d`) has golangci-lint v2.12.2 with `.golangci.yml` and the slog attribute fix; `next` (`ac3031a`) has the `script/` scaffold, the Makefile shims, the workflow running `script/cibuild`, and `REPO_POLICIES.md`. Neither contains the other. This unit brings `main` into `next`, and the scaffold reaches `main` when sneak merges `next`. That is how his "proceed with a release" ruling above gets carried out under the current branch rules.
1. Branch `sync-main-into-next` from current `next`. Merge `origin/main` into it as a real two-parent merge: no rebase, cherry-pick or squash, so that `main` becomes an ancestor of `next` and the later `next`-to-`main` merge does not conflict.
2. Only `README.md` and `TODO.md` conflict. Resolve both by hand and keep both sides: `main`'s handler documentation and `next`'s Entrypoints section; both sides' completed steps. Correct any sentence the merged tree makes false, and add nothing else. The `Dockerfile` merges cleanly to `main`'s v2.12.2 lint image.
3. Item 4 (the `Dockerfile` runs `make check`): judgement call to keep its separate `make fmt-check`, `make lint` and `make test` steps. Those are the three checks `script/check` runs, so the image build already fails on any check failure, and a single `make check` step would have to change again when https://git.eeqj.de/sneak/simplelog/issues/20 moves the linter into its own docker build.
4. `.golangci.yml` stays unchanged. https://git.eeqj.de/sneak/simplelog/issues/20, https://git.eeqj.de/sneak/simplelog/issues/22 and https://git.eeqj.de/sneak/simplelog/issues/23 are separate units that start from `next` once this one lands.
5. `script/cibuild` must pass, with the three check steps actually executed and not served from the build cache.
6. The PR targets `next` and is titled `Bring main's fixes into next (closes #16)`. On a passed review the manager merges it with Gitea's merge-commit style, not squash, for the ancestry reason in step 1. That deviates from the one-squash-per-issue rule; it applies only to this unit. Before pushing, the worker merges (never rebases) any newer `next` into the branch.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The
Makefilediverges from our standard scripts-to-rule-them-all (STRTA) scaffold. Under STRTA, theMakefileis a set of thin shims that delegate toscript/*POSIX-shentrypoints, and CI runsscript/cibuild. The living reference is thenetwatchrepo (Makefile+script/+.gitea/workflows/check.yml); mirror it exactly.Current state (nonconformance)
Makefiletargets are inline recipes rather than@script/*shims:test,fmt,fmt-check,lint,check,docker, andhooksall contain inline commands.bootstrap,setup.script/directory..gitea/workflows/check.ymlexists but runsdocker build .directly instead ofscript/cibuild.Definition of done
Makefilehas a.PHONYdeclaration listing at least the nine standard targets:bootstrap,setup,test,lint,fmt,fmt-check,check,docker,hooks.@script/NAME(testcalls@script/test,hookscalls@script/install-precommit, etc.). Repo-specific extra targets are allowed but must not replace the standard shims.script/directory holds executable POSIX-shentrypoints (#!/bin/sh,set -e) forbootstrap,setup,test,lint,fmt,fmt-check,check,docker,install-precommit, pluscibuild. The real logic currently inline in theMakefilemoves into these scripts.script/checkruns the repo's full local verification (fmt-check+lint+test);script/cibuildis the CI entrypoint (typicallydocker build .), and theDockerfilebuild runsmake checkso the image build fails on any check failure..gitea/workflows/check.ymlinvokesscript/cibuildrather than a baredocker build ..make checkpasses locally anddocker build .succeeds (green) before the change lands.The finishing commit's title must end with
(closes #N)referencing this issue.Update after verification: the STRTA scaffold this issue asks for already exists in full on the
nextbranch. That branch'sMakefileis thin@script/*shims for all nine standard targets, backed by a completescript/set includingscript/cibuild; it landed there on 2026-07-07.mainis divergent by design: simplelog is post-1.0.0 (tagged1.0.1), and under our branch conventionmaincarries only the current released version, withnextmerged tomainand tagged on each release. So the fix formainis not to re-implement the scaffold here — it is to releasenexttomain.Because that is a release/versioning call, it is yours to make:
nextintomainand tag a new version (1.0.2, or 1.1.0 given the new scaffolding), which lands STRTA onmainand closes this issue.mainis unprotected, so I can perform the merge and tag on your go-ahead.mainas-is until the next planned simplelog release, which will carry the scaffold along automatically.Recommendation: (a), unless you are holding simplelog's release for other pending work — in which case (b). Tell me which, and the version string for (a), and I will land it. I have stood down the redundant fixer subagent I had dispatched against
main.proceed with a release. 1.1.0 is fine.
clawbot referenced this issue2026-08-10 14:39:53 +02:00
clawbot referenced this issue2026-09-03 15:06:34 +02:00
clawbot referenced this issue2026-09-03 15:06:57 +02:00
clawbot referenced this issue2026-09-04 00:06:38 +02:00
State, 2026-10-03 12:40 UTC: queued first in this repo, no worker started (manager stood down for RAM).
mainandnextwere both green at7f0cd5dandac3031a.Plan. The scaffold this issue asks for is already on
next; what is missing is thatnextandmainhave diverged.main(v1.0.2,7f0cd5d) has golangci-lint v2.12.2 with.golangci.ymland the slog attribute fix;next(ac3031a) has thescript/scaffold, the Makefile shims, the workflow runningscript/cibuild, andREPO_POLICIES.md. Neither contains the other. This unit bringsmainintonext, and the scaffold reachesmainwhen sneak mergesnext. That is how his "proceed with a release" ruling above gets carried out under the current branch rules.sync-main-into-nextfrom currentnext. Mergeorigin/maininto it as a real two-parent merge: no rebase, cherry-pick or squash, so thatmainbecomes an ancestor ofnextand the laternext-to-mainmerge does not conflict.README.mdandTODO.mdconflict. Resolve both by hand and keep both sides:main's handler documentation andnext's Entrypoints section; both sides' completed steps. Correct any sentence the merged tree makes false, and add nothing else. TheDockerfilemerges cleanly tomain's v2.12.2 lint image.Dockerfilerunsmake check): judgement call to keep its separatemake fmt-check,make lintandmake teststeps. Those are the three checksscript/checkruns, so the image build already fails on any check failure, and a singlemake checkstep would have to change again when #20 moves the linter into its own docker build..golangci.ymlstays unchanged. #20, #22 and #23 are separate units that start fromnextonce this one lands.script/cibuildmust pass, with the three check steps actually executed and not served from the build cache.nextand is titledBring main's fixes into next (closes #16). On a passed review the manager merges it with Gitea's merge-commit style, not squash, for the ancestry reason in step 1. That deviates from the one-squash-per-issue rule; it applies only to this unit. Before pushing, the worker merges (never rebases) any newernextinto the branch.Model: opus-5-5