Require run evidence for platform claims and forbid host-bound paths

[teslamint]

Problem

The lifecycle skills verify behaviour on the machine where the work runs. None of them asks whether a claim or a path holds on a different machine.

A recent project showed how this fails. All checks passed, and review rounds read the same files on the same machine. A clean setup on a second operating system then failed as follows:

1. The README claimed support for two operating systems. Every run had used one OS and one CPU architecture. No session contained the second OS.
2. Five scripts and tests hard-coded host-specific binaries: a package-manager install prefix for the container runtime, a Homebrew prefix for a media tool, and two binaries that exist only on macOS.
3. A generated license inventory stored paths from a case-insensitive filesystem. On a case-sensitive filesystem, 101 of 842 paths did not resolve, and the app did not start.
4. A submission inventory stored absolute home-directory paths. Its own verifier therefore failed on every other machine and in every other clone location.
5. A test read a local .env value that overrode the test's own input. The test then failed when the documented setup was followed.

The planning, reviewing, and shipping skills gave no prompt to catch any of these. The review loop could not catch them either, because every reviewer ran in the same environment.

Proposal

Add one rule where environment assumptions enter the work:

A platform or compatibility claim names the environment where it was run, or says "unverified". Committed code and data do not contain host-specific absolute paths.

Suggested placement:

1. designing / planning: the plan lists the target environments as a requirement. For each environment, it names the verification that proves it (for example, a CI runner or a container). An environment without a named verification is written as "unverified".
2. implementing: resolve tools from PATH or from an environment override. Keep machine-specific values out of committed files, and do not write absolute home paths into generated artifacts.
3. reviewing: add a finding category for two cases: a platform claim without run evidence, and a host-bound path (home directory, package-manager prefix, OS-only binary). A review of setup docs executes them in a second environment, or it records that as a gap.
4. shipping / release: generate the list of verified environments from recorded runs, not from hand-written prose.

Enforcement notes

Wording alone did not prevent this. Equivalent rules already existed in always-loaded agent instructions, and they did not stop the claim. A deterministic check is the part that holds. Lessons from a commit-time prototype:

• Check only the lines that a commit adds, so that older repositories can adopt the check at once.
• A platform claim is an OS name together with a support or run verb. A conditional instruction such as "on Linux, use X" is not a claim.
• A guard that cannot resolve what it would check must block, not skip. Each of these was a bypass until the guard blocked it:
  • a commit directory given through a variable or command substitution
  • a directory that does not exist, or that is not a repository yet
  • a subshell cd that leaks into later commands
  • GIT_DIR, GIT_WORK_TREE, and related variables set inside the command
• A command-string hook cannot see state from earlier commands, sh -c, or aliases. The git-level pre-commit hook and a CI job on a second OS close those gaps.

Acceptance criteria

1. The planning self-review lists target environments, and a named verification for each or "unverified".
2. The reviewing skill can raise an unverified platform claim or a host-bound path as a finding.
3. The implementing guidance says to resolve tools from PATH or an override, and forbids absolute home paths in committed artifacts.
4. The wording is general. It names no consuming project, test, or path.
5. Conformance fixtures and skill digests are updated through the normal release-loop.

Related

• Require a named defect before adding a gate or verifier #38: the named defect for this rule is the failure set described above.
• Move generic review-evidence integrity into compound-loop #37: an evidence-integrity check that records absolute paths reproduces failure 4.