Nothing says the suite is only observed on Linux, and a macOS contributor unclaimed a working fix over it

[vladimirrott]

Command corrected 2026-09-14 at 61b3a878. The first block printed the
wrong field: with grep -n the line begins with the line number, so $2 is
the literal runs-on: and the pasted ubuntu-latest reproduces on no commit
this repository has. My error when I filed it, and nothing has changed
underneath. $3 is the field, the answer is still a single value, and the
second command still returns nothing:

$ git rev-parse --short=8 HEAD
61b3a878
$ grep -n 'runs-on' .github/workflows/ci.yml | awk '{print $3}' | sort -u
ubuntu-latest
$ grep -rni 'macos\|linux only\|linux-only' README.md CONTRIBUTING.md HACKING.md
(nothing, exit 1)

Every job in .github/workflows/ci.yml is runs-on: ubuntu-latest, so the
workspace suite has only ever been observed on Linux. Nothing in README.md,
CONTRIBUTING.md or HACKING.md says so:

$ grep -n 'runs-on' .github/workflows/ci.yml | awk '{print $3}' | sort -u
ubuntu-latest
$ grep -rni 'macos\|linux only\|linux-only' README.md CONTRIBUTING.md HACKING.md
(nothing)

The daemon is #[cfg(target_os = "linux")] in the places that matter, and the
whole product is a Linux administration tool, so a macOS checkout failing parts
of the suite is expected. A contributor has no way to know that in advance.

What it cost

On 2026-09-08 a contributor claimed #397, validated their fix locally, and
unclaimed it four minutes later:

I'm unclaiming this after local validation: the focused regression test
passes, but the repository's required daemon suite has 10 unrelated
platform/global-state failures on macOS (874 passed).

Their focused test passed. They did the disciplined thing with the information
they had, which was a red suite and no document saying which reds are theirs.
That is a working contribution lost to a missing paragraph.

The research on this is not ambiguous: build environment is one of the
top newcomer barriers,
and it acts on everyone at once, including the people who never comment.

Scope

• Say in CONTRIBUTING.md which platforms the suite is expected to pass on, and
  that CI observes Linux only.
• Name the honest subset for a non-Linux checkout. cargo test -p sysknife-types
  and -p sysknife-core are the obvious candidates, but the list should be
  measured on a real macOS box rather than reasoned about from #[cfg] lines.
• Say what to do with a red daemon suite on macOS: which failures are structural
  and how to tell them from a regression the contributor introduced.
• If a filter or a feature flag can express "the platform-independent subset",
  that is better than prose, because prose about test selection goes stale in
  exactly the way this repo keeps writing issues about.

Difficulty

Easy, and it needs somebody on macOS to measure it rather than somebody on Linux
to guess. The measurement is the deliverable.

Tests first

The deliverable here is a measurement rather than a patch, so the order is
inverted: run the suite on macOS and paste the output before writing a word of
prose. What lands in CONTRIBUTING.md has to be the list you observed, not the
list a Linux reader inferred from #[cfg] attributes.

1. cargo nextest run --workspace --locked on a macOS checkout. Paste the full
   failure list, with counts. The 2026-09-08 report was ten failures against 874
   passing; whether that still holds is the first thing this issue does not know.
2. Sort those failures into two piles and say which is which: structural (the
   daemon needs Linux and always will) and incidental (a temp-dir assumption, a
   path separator, something that would be worth fixing).
3. Name the subset that passes. cargo test -p sysknife-types and
   -p sysknife-core are the candidates, and they are candidates rather than the
   answer until somebody runs them.
4. If a package filter or a feature flag expresses that subset, write it down as a
   command instead of a paragraph. Prose about test selection goes stale in
   exactly the way this repository keeps filing issues about.

A guard is worth adding only if step 4 produces a command: a check that the
command named in CONTRIBUTING.md still selects a non-empty set. A documented
cargo test -p X that silently selects zero tests is the failure this repo has
already been bitten by.

Getting started

CONTRIBUTING.md
has the build and test commands. You need a macOS machine and a Rust toolchain,
and nothing else: no VM, no daemon, no provider credentials.

If your suite comes back red, that is the data. Paste it here before deciding
whether any of it is your fault; sorting that out is what the issue is for, and
it is the part nobody has done.

No CLA and no copyright waiver. The project is MIT.

[vladimirrott]

@nightcityblade offered this to you on #397, and repeating it here so it lives on the issue rather than in another thread.

You found this the hard way on 2026-09-08: a red daemon suite on macOS, 874 passing, no document saying which of the ten reds were structural. The fix is the measurement, and it has to come from a macOS checkout. Anybody working from Linux would be reasoning off #[cfg] lines, which is how the paragraph goes stale again.

No Linux host, no VM, no daemon needed. Yours if you want it, and no is a complete answer.

[vladimirrott]

@nightcityblade I pointed you at this on 9 September and have not heard back, so I am putting it back in the pool. No deadline was missed and nothing is owed.

If you still want it, say so and it is yours again.

[vladimirrott]

@iamjaeholee following on from what I said above: this smaller one may fit better, if you want it.

You have spent both your merged changes inside the test guards, #349 and #365, so you know the suite better than most. #411 is about what the suite does not say: nothing states that it is only ever observed on Linux, so somebody on macOS runs it, watches it behave oddly and has no way to tell whether that is their machine or a real failure.

Easy, and mostly a question of writing down what is actually true. Say what is observed, where, and what is untested rather than broken.

No deadline. If you would rather have something with code in it, say so and I will find you one.