Consumption patterns
The marketplace is a 3-tier taxonomy. Consumption rules differ per tier.
Foundation: secure-baseline is always pinned explicitly
Section titled “Foundation: secure-baseline is always pinned explicitly”Every consumer redeclares secure-baseline in its own apm.yml. Phase kits
do not declare secure-baseline as a transitive dep
(every phase kit ships with dependencies.apm: []). This is intentional.
Why no transitive shortcut? APM resolves transitive conflicts on a
first-wins basis. For a tool dependency that is acceptable; for a
security floor it is not. If two phase kits transitively pulled
secure-baseline at different refs, the resolver would pick one silently,
downgrading or upgrading the secure-coding instructions without an audit
trail. Forcing every consumer to declare the floor explicitly means:
- A
grep -r secure-baseline */apm.ymlproves coverage across the org. - Renovate / Dependabot bumps land in the consumer’s PR diff, not buried in a transitive lockfile change.
- A CI presence check can fail the build if the floor is missing — uniform across consumers because the pin is in a uniform location.
Phase kits: pin only the phases your repo actually exercises
Section titled “Phase kits: pin only the phases your repo actually exercises”Pin ideate-kit only if your repo receives unstructured input that becomes
issues. Pin operate-kit only if you wire Azure SRE Agent. Don’t pin kits
you don’t use — apm install is fast but compile-time scope hygiene matters.
Accelerators: pin on demand, not by default
Section titled “Accelerators: pin on demand, not by default”modernize-kit is opt-in — consumers add it when they have a planned
framework migration and remove it once the migration completes; accelerators
are episodic, not compounding.