[pasrom]

Why

A pull request that a workflow opens with GITHUB_TOKEN starts no pull_request run, so a bot pull request (a pin bump) shows no check. workflow_dispatch is the one trigger GITHUB_TOKEN may start: with it, the bot dispatches ci.yml on its branch, and the run's check shows on the pull request's head commit.

What changes

• templates/team/ci.yml gets workflow_dispatch: under on:, with a comment saying why. A dispatched run does not serve: km serve and the upload stay gated on push.
• km upgrade: it rewrites ci.yml only when the file is one of the copy-in versions (OLD_COPIES fingerprints), and a 1.x ci.yml never matches them, since its pin line differs per brain. Every other km ci.yml only had its pin moved, so the trigger would never reach an existing brain. Smallest change: for a team brain whose ci.yml pins km (read_pins), with_dispatch() adds workflow_dispatch: at the end of the on: block, at the block's indent. The result must parse to the same workflow with exactly that trigger added, otherwise nothing is written and upgrade says to add it by hand (a one-line on: [push, pull_request], say). A workflow that already has the trigger, in any form, is left as it is. A ci.yml that does not install km is not touched.
• README: one paragraph on the trigger.

Tests (team_smoke.sh)

init writes the trigger; a copied-in ci.yml is rewritten with it; upgrade adds it to a km ci.yml without it and changes nothing else (parsed before and after); a second upgrade changes nothing; a comment naming the trigger does not count as the trigger; an on: block at the end of a file without a final newline; a one-line on: gets the hand-edit note and no write; a team brain's ci.yml that does not install km gets no trigger. Each was checked to fail without its part of the change (template, the upgrade step, the ci in pins guard, the final-newline handling).

Reviews

/simplify, applied: one parse helper instead of two try blocks; reuse read_pins to decide that ci.yml is km's instead of a second read and substring test; decide "has the trigger" from the parsed on: instead of a substring, so a comment does not count. Not applied: share a block scanner with with_team_hooks in init.py. That one walks a YAML list of repo entries (top-level - and comment lines inside the block), this one a mapping; a shared helper would carry both cases for about ten lines saved.

/code-review, applied: the ci.yml key compared with a forward-slash literal while read_pins keys use the OS separator, so on Windows upgrade never added the trigger (now built with Path); the test for a brain's own ci.yml could not fail (now a team brain whose ci.yml has an on: block but no km pin); the final-newline case. Not applied:

• A brain's own ci.yml that also pins km gets the trigger. It is the same signal upgrade already uses for "a team brain", the edit adds one trigger and nothing else, and upgrade prints it.
• ci.yaml is not looked at: km writes ci.yml.
• The hand-edit note repeats on every upgrade until the trigger is there, like the hook notes.
• A run dispatched by hand on main builds no served bundle: the gate keeps meaning "push to main"; a dispatch is for checks.
• Nothing in km dispatches ci yet: the workflow that does (moving the mounted pins) is the next pull request, stacked on this one.
• CRLF ci.yml: brains get * text=auto eol=lf.

All smoke tests pass locally. No change under skills/km/, so the plugin evals do not apply.