docs(release): exclude extension items shipped from their own repository from the release trigger #500

The problem (CMO)

Agent role: Chef in brigade-mode (escargot), batch that marked the XT-107 cards done

Area: Steering files

Problem Statement: As an agent working in pascalandy/nicely, I want the release trigger to say whether an extension item shipped from its own repository takes a Nicely release, so that the agent that merges its last card knows at once whether to run release-nicely.

REF: #494, #499

Analogy

A school rule says "ring the bell when a class finishes a project". A second rule, in another binder, says "projects done at the art studio across the street keep their own bell". When the art studio's project was done, a teacher who read the first rule walked toward the bell.

• What should happen: the bell rule itself says that projects from the art studio don't ring this bell
• What happened in 📚 docs: backlog: mark XT-107 cards done #499: the agent read the first rule, got ready to ring, then found the second rule and stopped

What we saw

#499 set the three XT-107 cards to done. docs/backlog/README.md#cards then requires the item to become Shipped, because it has no todo card left.

• D043 says: "Release when an item becomes Shipped on origin/main, without a request or an acceptance."
• release-nicely says it is for "a merge that makes a Nicely item Shipped".
• Neither one says anything about an extension that ships from its own repository.

So the agent planned a v0.28.0 release from main, which held only 4 docs commits since v0.27.0. It sent two questions up its chain, generated the changelog and started just release-check. Then it read D065: "Each item that ships from Nicely takes the next minor version… An extension maintained in its own repository, such as XT-101, keeps its own versions." It cancelled the release before any tag was made. XT-101's state, "Shipped at v0.1.1 in pascalandy/ncly-video-convert", is the same case.

Cost: two escalations, a discarded release checkout and a partial release-check run. Without D065, an empty Nicely release would have shipped. Releases tag and publish, so they are hard to undo.

What exists today

D065 has the right rule, but it sits in a decision about plan IDs and versions. The two files an agent reads at release time, D043 and release-nicely, do not point to that rule.

Start, Stop, Continue (FMO)

• Start: D043 and the description of release-nicely say that only an item that ships from Nicely triggers a Nicely release. An extension item that ships from its own repository, such as XT-101 or XT-107, uses that repository's release
• Stop: treating every Shipped backlog item as a Nicely release trigger
• Continue: a Nicely-shipped item takes the next minor version, and a merged fix of a released behavior takes a patch

How we'll know it works

1. Today: read D043 line "Release when an item becomes Shipped on origin/main" with XT-107 Shipped: it asks for a Nicely release
2. After the change: the same lines exclude XT-107 and XT-101 without reading D065
3. Nothing else changes: COR-102, a core item, still triggers a release when it becomes Shipped

👨🏻‍🍳 For the agent

by Opus-5.5 via Claude Code