No workflow-authoring conventions page, so concurrency lessons keep being relearned per workflow

[realmarcin]

Raised in the review of #216, deferred out of it deliberately.

#216 fixes the third concurrency-scoping bug in this fleet:

• vendored-sync: cancel-in-progress can skip verification of an intermediate main commit #199 — vendored-sync's cancel-in-progress could skip verification of an intermediate main commit.
• Run vendored-sync on every PR instead of almost never (#184) #196's review — concurrency scoped too broadly, narrowed to PRs.
• claude-code-review cancels itself: its own progress comment fires issue_comment into the same concurrency group #215 — claude-code-review cancelled itself, because its own progress comment fired issue_comment into the shared group.

Three instances, three separate diagnoses, three long explanatory comment blocks living inside individual workflow files. The knowledge is real and hard-won, and it is currently discoverable only by whoever happens to open the file that already has it.

docs/ has no workflow-conventions page to put it in, which is why #216 did not add one — inventing a docs page inside a one-line concurrency fix would have been the wrong scope.

What is worth writing down

• Cancellation is for superseding, not deduplication. Only key a group across runs you genuinely want to supersede one another — in practice, pushes to one PR. Give everything else a unique key (github.run_id) rather than reasoning about whether it will collide.
• Concurrency versus if:. GitHub documents jobs.<job_id>.concurrency but never says whether a job skipped by a false if: acquires the group. Do not build a fix on either answer; make the key structurally distinct instead.
• issue_comment and schedule workflows run from the default branch's copy of the file. A workflow can be correct on its feature branch and broken the instant it merges, with no pre-merge signal — exactly how claude-code-review cancels itself: its own progress comment fires issue_comment into the same concurrency group #215 got in.
• A paths: filter is a promise that the job does not need the files it excludes. vendored-sync never fires for 5 of the 6 files it checks (paths filter is narrower than the drift list) #184 and A PR touching only docs/ or a new workflow file gets zero CI checks #200 are both this.
• Verify the check ran, not just that it was green. Re-converge drift check on CultureMech hub; extend to mech_shared; retire schema-pin #182, vendored-sync never fires for 5 of the 6 files it checks (paths filter is narrower than the drift list) #184 and claude-code-review cancels itself: its own progress comment fires issue_comment into the same concurrency group #215 were all "green because nothing evaluated it".

Cross-Mech

This is fleet knowledge, not TraitMech knowledge — all four Mech repos share the workflow patterns and CultureMech is the hub. The page probably belongs there or in culturebotai-claw alongside docs/AGENT_IDENTITY.md, with the spokes linking to it, rather than being copied four times and drifting (see #209 for how that goes).