6 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
user	2fcb3e6ced	test(lint-once): follow a short file flag with its value attached ... `docker build -fDockerfile.lint .` is a plain `-f` naming a literal file — the flag parser reads the attached value for any shorthand — but the resolver's `[=\s]+` required a separator, so the invocation fell through to the default `Dockerfile` edge. Mutating the `check` recipe to that spelling left the suite 52/52 green while `-f Dockerfile.lint` was caught. The header already promised this form was followed: it claimed the file named by `-f` is resolved wherever the flag sits, and disclosed only a bundled short cluster (`-qf <file>`) as unfollowed. Overclaiming is the defect, so the resolver is taught the form rather than the claim narrowed. The attached form is allowed only for the short flag, keeping `--force-rm` out of it; `--file` still requires `=` or whitespace. The `-qf` cluster limitation is untouched and still pinned.	2026-09-04 11:37:08 +00:00
user	197296edba	lint-once: follow every spelling of docker build's file flag ... The edge resolver matched `-f <file>` only. `docker build --file=X` fell through to the default `Dockerfile` edge, so a second prettier pass wired in that way was followed into the wrong file, counted nothing, and left the suite green -- the exact false green this test exists to prevent, reachable by writing the flag the long way. Mutation, adding one line to the `check` recipe, before this commit: @docker build -f Dockerfile.lint . 1 failed / 47 caught @docker build --file=Dockerfile.lint . 48 passed / 48 MISSED After, all four spellings fail with `expected 2 to be 1`: `-f X`, `-f=X`, `--file X`, `--file=X`. Docker takes the value either way for both the short and long flag, so the resolver now reads `(?:-f|--file)[=\s]+`, still searched anywhere in the invocation rather than at a fixed position. A leading \s keeps a longer flag ending in the same letters (`--force-rm`) from supplying the match. The header claimed `docker build -f <file>` coverage without qualification, which a reader could take to include the long form it did not follow; it now names all four forms and the fallback. The one limitation it asserts -- a bundled cluster like `-qf X` resolving to the default -- is pinned by a test, since an unpinned limitation is how the header drifts back into overclaiming.	2026-09-04 11:31:06 +00:00
user	bd88eced84	README: state the container-lint claim as what is actually true ... The Linting section this PR adds claimed "There is no host lint path" and then, two paragraphs later, documented script/fmt-check as a host-side formatting check. Both cannot be true, and the absolute one is the false one. What is true is narrower: no lint path reachable from script/check or script/precommit runs on the host, so every lint verdict those two produce comes from the container. script/fmt-check stays as a standalone entrypoint, now stated as the one host formatting path with nothing reaching it. The "exactly one place" and "in the container only" phrasings elsewhere are qualified the same way.	2026-09-04 11:27:49 +00:00
user	956870889f	Update the make variable header to match the ?= and prefix rules	2026-09-04 11:19:45 +00:00
user	18b0f039b5	Pin the export/override prefix and ?= first-wins with tests	2026-09-04 11:18:19 +00:00
user	18226d345b	WIP: fix export/override prefix and ?= first-wins in make variable parser ... Two defects in the lint-once resolver's make variable handling: - The assignment pattern anchored at the start of the name, so `export FMT := script/fmt-check` was never collected and `@$(FMT)` went unresolved. An optional `export `/`override ` prefix is now allowed. - `?=` assigns only when the name is unset, so the first assignment wins. The parser called .set() unconditionally, letting a later `FMT ?= script/build` overwrite an earlier `FMT := script/fmt-check` and resolve to a command make never runs. Tests pinning both to follow.	2026-09-04 11:17:32 +00:00