Re-carry AGENTS.md, WORKFLOW.md, and publish-plan-task.yml: the hub adopted both upstream proposals, with changes

[ptr727]

Filed from the hub (ProjectTemplate) to close the loop on two upstream issues raised from this repo. Both are landed at the hub, and both were adopted with changes, so this repo's local copies now differ from the canonical ones. Nothing here is broken - this is a convergence task for the next conformance touch.

1. publish-plan-task.yml - fail-loud gate (hub #354, from this repo's #138)

The hub adopted option 1: a main push by an actor outside the allowlist now emits a ::warning:: instead of silently skipping publish. This repo's .github/workflows/publish-plan-task.yml does not carry that branch yet:

              if [[ "$REF" == "main" ]] && { [[ "$ACTOR" == "ptr727-codegen[bot]" ]] || [[ "$ACTOR" == "dependabot[bot]" ]]; }; then
                publish=true
              elif [[ "$REF" == "main" ]]; then
                # Fail loud: an unrecognized actor pushing to main is either a human commit (legitimately not
                # publishing, but worth seeing) or a release bot under a new identity, which would otherwise
                # stop publishing silently while a schedule keeps releasing - lost timeliness, no error.
                echo "::warning::Push to main by unrecognized actor '$ACTOR'; not publishing. If this is a release bot under a new identity, update the allowlist in publish-plan-task.yml."
              fi

One deliberate wording change worth knowing: the message says "Push to main", not "Pin push on main". Copilot review at the hub pointed out that this task is the generic publish gate every publish-release job reuses, not just the upstream-version pin flow - pin-specific wording would misread for other consumers. If you were planning to implement this locally, please take the generic wording rather than re-deriving it from the issue text, which was written from the pin-tracker vantage.

The publish decision itself is unchanged - simulated at the hub across codegen/dependabot/renamed-App/human x main/develop, plus schedule and dispatch: identical publish= results, warning only on the silent-failure path.

2. AGENTS.md - Verification Discipline (hub #356, from this repo's #165)

The hub adopted the section, and the amendment added a seventh rule plus a companion after your implementation landed. Current differences between this repo's copy and the hub's:

	this repo	hub
Rules in ## Verification Discipline	6	7 (adds "A review flags an instance; fix the class")
Behavior-change prose sweep	absent	present, under Documentation Style Conventions (not Verification Discipline)
Section placement	after PR Review Etiquette	between Documentation Style Conventions and PR Review Etiquette
Cross-references	none	each generalization points at its narrower instance
CRLF rule	regex CRCRLF case	also names the mirror failure: a text-mode rewrite silently flattens CRLF to LF

Two placement calls the hub made that are worth flagging, since the amendment did not specify them:

• Rule 7 went under Documentation Style Conventions, per the amendment's placement note, beside the present-tense rule as its maintenance counterpart - that rule governs how to phrase a doc, this one how to keep it true when the behavior underneath moves.
• The companion ("fix the class") went into Verification Discipline, not the docs section. The amendment grouped it with rule 7 but did not place it; the hub judged that it generalizes past stale prose to any flagged defect class (a silent-narrowing pattern, a mis-worded contract). If you disagree, say so here - it is cheap to move at the hub.

The section placement difference (before vs after PR Review Etiquette) is the one that will show up as a diff on re-carry. The hub's reasoning was the reading order: write it right -> verify it -> review it.

3. WORKFLOW.md - new guarantee

D8.4 now codifies the generalization: an identity allowlist used as a gate fails loud. It records that an annotation is optional where the failure is self-announcing - the merge-bot hard-codes the same identities, but when it stops matching, bot PRs visibly pile up; the publish gate is the acute case precisely because the weekly schedule masks it into a pure timeliness symptom.

Suggested action

On the next conformance touch, re-carry AGENTS.md, WORKFLOW.md, and .github/workflows/publish-plan-task.yml from the hub. No urgency - the current state is correct, just behind.

Thanks for both proposals; they were well-evidenced and landed close to as written.

[ptr727]

Follow-up: the cross-repo rule is amended upstream, so your local amendment can converge

The over-application you hit - Copilot requiring removal of a README.md link to the related device-builder repo - was a defect in the rule, not in the review. Fixed upstream, so your local amendment does not need to stay a divergence.

Two things were wrong with how I had written it:

1. It led with the mechanism and buried the carve-out. It opened with "adds no link to another fleet repo" and only qualified that with "unless that repo is the subject" fifteen lines later. Read top-down, the ban looks absolute - which is exactly how it got applied.
2. It listed README.md as carried verbatim, which is wrong. spec/files.json gives README.md neither whole nor sections, so it is a per-repo file governed only by README structure. A repo's own README is its own content and the rule never should have reached it.

The rule is now stated by intent. Banned: any reference to the template repo, and a sibling fleet repo named as an illustrative example of a rule or adoption. Explicitly permitted:

A contextually relevant link to a related project is not a coordination reference, and is expected. Where another repo is part of this repo's subject matter - the image that consumes this config, the builder that generates this hardware, a library this depends on - link it normally. The test is whether the link serves a reader of this repo's content, not whether the target happens to be in the fleet.

Plus the scope correction: the rule governs carried template content, not a repo's own README and topical docs.

So the device-builder link is legitimate and should stay. On your next carry of AGENTS.md this wording arrives and your local amendment converges rather than diverging.

Worth noting for the general case: the mechanical check in spec/audit.py was never the cause - it greps only for the template name in the two agent-instruction files and has never looked at sibling links. This was purely the prose being misreadable.

No reply needed.