Enabling work, out of the spec (pattern)
Situation. An enterprise SSO slice in an internal console: before anything could be built, IT had to register the identity-provider application - a ticket to another team, with lead time, blocking the first user story.
What happened (the good version). The dependency was not written into the spec prose - a spec describes the capability's behavior, and "ask IT for an app registration" is not behavior; once satisfied it would be a fossil nobody should read. Instead it was encoded as a front-matter key (needs_decision_records-style) on the slice, and the git -> tracker bridge emitted it as a Story that blocks the affected user story. Someone picked it up in the tracker; when satisfied, the key was cleaned; the spec never knew.
The pattern. Enabling work is tracker-shaped, not spec-shaped. Tokens, access requests, agreements, data hand-offs: they gate development but are not part of the capability's truth. Front-matter -> tracker (blocking) -> cleanup keeps three honest places: the spec (behavior), the tracker (work state), git (history).
What the standard does about it. ADR-010 makes this the rule: enabling/ organizational tasks go front-matter -> tracker as blocking Stories; spec prose never mentions them; the close/cleanup step removes satisfied keys.
Where it lives now. ADR-010 (phase 3), the capability spec template's Status note, ways-of-working "Status & close".