From 735c50f351a8f21364e174d076b88d9c4e658bbe Mon Sep 17 00:00:00 2001 From: John Preston Date: Thu, 27 Aug 2026 13:50:17 +0400 Subject: [PATCH] [ai] Stop routing platform checks for build breakage Every platform is built before anything merges, so a build or link break is found there instantly. A platform follow-up now needs platform-specific code and a concrete reason to suspect that platform. --- .agents/skills/continue/SKILL.md | 27 +++++++++++++------ .../perform-task/references/pipeline.md | 22 ++++++++++----- 2 files changed, 35 insertions(+), 14 deletions(-) diff --git a/.agents/skills/continue/SKILL.md b/.agents/skills/continue/SKILL.md index f6dbab1807..8941969d8c 100644 --- a/.agents/skills/continue/SKILL.md +++ b/.agents/skills/continue/SKILL.md @@ -535,14 +535,25 @@ 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. +non-trivial platform-specific mechanisms `pipeline.md` lists for `Unverified:` +— `#ifdef` or platform-API code, filesystem path semantics, +process/thread/event-loop ordering, or acceptance criteria stated per platform +— *and* the entry states a concrete reason to suspect that platform gets it +wrong. Name that mechanism and that suspicion in the receipt. The bare +existence of a platform-specific surface is not a suspicion. + +Never route a task whose purpose is to confirm that another platform still +builds or links. Every platform is built and tested before anything merges to +`dev` or ships, so a build break surfaces there immediately and for free, +while the task costs hours. This covers a dependency or submodule pin that +another platform's toolchain consumes, compiler flags and their diagnostics, +CMake platform branches, and ABI or symbol resolution — however the source +result worded its `Unverified:` line, and even when a capable host is idle. +Record it in the discovery receipt only. + +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. 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 diff --git a/.agents/skills/perform-task/references/pipeline.md b/.agents/skills/perform-task/references/pipeline.md index 2b7accbdaa..8ccdc2f348 100644 --- a/.agents/skills/perform-task/references/pipeline.md +++ b/.agents/skills/perform-task/references/pipeline.md @@ -865,21 +865,31 @@ 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. +Another platform or architecture qualifies only when the diff carries +non-trivial platform-specific code *and* you can state a concrete reason to +suspect that platform gets it wrong. Having executed on one host is not itself +a gap, and neither is the bare existence of a platform-specific surface. 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: +verifies them and this line reads `none`. Name the mechanism and the suspicion +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. +Whether the change still compiles and links on another platform is never such +a gap. Every platform is built and tested before anything merges to `dev` or +ships, and a build or link break is loud, immediate and free to find: the +compiler names the file and the line the first time that platform builds. +An `Unverified:` line for it buys a multi-hour task to learn what the next +build reports in seconds. This holds for a dependency or submodule pin that +another platform's toolchain consumes, for compiler flags and the diagnostics +they enable, for CMake platform branches, and for ABI and symbol resolution. +Say what moved in the result prose if it is worth saying; do not write it here. + 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,