[ai] Verify cross-platform code once

Treat another platform as an Unverified: gap only when the diff carries a platform-sensitive mechanism, and drop a second-host re-run of portable behaviour in the discovered-follow-up scope filter.

.agents/skills/continue/SKILL.md

@@ -517,8 +517,20 @@ project, apply the ordinary project-selection rules from `process-inbox`.
 First apply the scope filter, before any disposition. A coverage follow-up
 exists to prove **the source task's own change**, so run the revert test on each entry: if
 reverting that task's diff could not change the outcome, the entry is about
-pre-existing behavior and no coverage task is created for it. Untested code the
-run passed on the way, a neighbouring feature, a parameter range the acceptance
+pre-existing behavior and no coverage task is created for it.
+
+The same filter drops a re-run of portable behavior on a second host. An entry
+naming another platform survives only when the source diff carries one of the
+platform-sensitive mechanisms `pipeline.md` lists for `Unverified:` — the
+build/link/toolchain surface, `#ifdef` or platform-API code, filesystem path
+semantics, process/thread/event-loop ordering, or acceptance criteria stated
+per platform. Name that mechanism in the receipt. Portable C++, localization
+values, layout and pure logic are verified once on any capable host: record the
+entry as out of scope and create no task, however the source result worded its
+`Unverified:` line. One implement task must not spawn a family of
+verify-on-each-platform successors.
+
+Untested code the run passed on the way, a neighbouring feature, a parameter range the acceptance
 never named, a pre-existing bug the performer noticed: record the observation in
 the receipt and stop there. If it deserves work it must earn its own task on its
 own merits, through the ordinary discovered-follow-up planner and with its own

.agents/skills/perform-task/references/pipeline.md

@@ -829,13 +829,33 @@ context, branch, overlay and build before it can measure what this process is
 already holding, so writing one you could have closed trades minutes for days.
 
 What legitimately belongs here is a gap this checkout cannot close: one that
-needs another platform or architecture, a second account, funded external
-value, real server-backed cloud state, a purpose-built bot, or hardware this
-machine does not have. Write it to be
+needs a second account, funded external value, real server-backed cloud state,
+a purpose-built bot, or hardware this machine does not have. Write it to be
 routable — the exact behavior that shipped without verification, and precisely
 what closing it would require — so the scheduler can record it rather than
 queueing work that would be unstartable the moment it entered the queue.
 
+Another platform or architecture qualifies only when the diff carries a
+platform-sensitive mechanism. Having executed on one host is not itself a gap.
+Portable C++, localization values, layout and styling, and pure logic behave
+the same everywhere the project builds, so one green run on any capable host
+verifies them and this line reads `none`. Name the mechanism before writing a
+platform exposure, and only these count:
+
+- the build, link, or toolchain surface itself — compiler flags and the
+  diagnostics they enable, CMake platform branches, ABI and symbol resolution;
+- code under `#ifdef` or a platform API, including a platform-specific
+  implementation of a portable interface;
+- filesystem path semantics, case sensitivity, file locking, permissions;
+- process, thread, or event-loop ordering, including teardown and shutdown;
+- anything the task's acceptance criteria state per platform.
+
+A diff with none of these is verified once. Do not write a platform exposure
+for it, and never write one merely because a batch plan named a host other
+than the one that claimed the task. Cross-platform code is verified once,
+approved, and left alone; a second host re-measuring the same portable
+mechanism buys no evidence and costs a whole task.
+
 Scope it to this task's own change, with its acceptance criteria as the boundary.
 `Unverified:` is for behavior **this diff** shipped without proof — apply the same
 revert test the test loop applies to a check: if reverting this task's diff could