fanhuadesenlinnn/tdesktop
1
0
Fork 0
mirror of https://hubproxy.babadafafafafa.cn/https://github.com/telegramdesktop/tdesktop synced 2026-09-20 08:03:45 +08:00
Code Issues Packages Projects Releases Wiki Activity

[ai] Stop routing platform checks for build breakage

Browse Source 
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.
This commit is contained in:
John Preston
2026-08-27 13:50:17 +04:00
parent e263a2b7f0
commit 735c50f351
2 changed files with 35 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files

27
.agents/skills/continue/SKILL.md
View File

@@ -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

22
.agents/skills/perform-task/references/pipeline.md
View File

@@ -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,