Metadata governance and package dependencies
Vulkro reads a governance policy file you control and checks your metadata against it: who owns each component, when it was last meant to be reviewed, and whether anything still references a component you have marked deprecated. It also walks the dependency relationship between installed managed packages and the rest of your metadata to surface packages nothing uses and components left orphaned by a package change.
Governance findings are policy-driven, so they only fire when you have declared a policy. They turn a spreadsheet of "who owns what and when do we review it" into an enforced, scannable artifact.
The governance policy file
The SF-META-GOV-0NN family reads its policy from a YAML file. By
default Vulkro looks for .vulkro-sf/metadata-governance.yaml at the
project root. Override the path with the VULKRO_SF_GOVERNANCE_FILE
environment variable when the policy lives elsewhere (for example a
shared governance repo mounted into CI).
The file maps metadata components (by type and API name, with glob support) to an owner, an optional review-by date, and an optional deprecated flag. Components absent from the file are not governed and do not trigger these findings.
SF-META-GOV-001: no owner
What triggers it. A governed component (or a component in a scope the policy declares as owner-required) that has no owner assigned in the governance file.
Why it matters. Unowned metadata is metadata no one will maintain, review, or retire. When an incident traces back to an unowned component, there is no one to page and no one accountable for the fix. Ownership is the precondition for every other governance control.
How to fix. Assign an owner (a person, a team, or a distribution list) to the component in the governance file. If the component is genuinely shared, name the team that holds the contract for it.
SF-META-GOV-002: past review-by date
What triggers it. A governed component whose review-by date in the
governance file is earlier than the scan date.
Why it matters. A component past its review date has drifted out of its own maintenance cadence. Security posture, sharing assumptions, and business relevance all decay over time, and the review date is the control that forces a periodic re-check. A stale review date means no one has confirmed the component is still correct.
How to fix. Review the component, confirm it still does what the
policy expects, and advance the review-by date. If the component is no
longer needed, route it through the candidate-unused retirement
workflow instead.
SF-META-GOV-003: deprecated but referenced
What triggers it. A component the governance file marks
deprecated: true that still has at least one inbound reference in the
metadata graph.
Why it matters. A deprecated component that is still referenced is a migration that stalled. Callers are relying on something the owning team has declared end-of-life, and the longer it stays referenced the harder the eventual removal becomes. This finding is the enforcement mechanism behind a deprecation decision.
How to fix. Migrate each remaining caller off the deprecated component, then remove it. The finding lists the referencing components so the migration scope is explicit.
SF-PKG-DEP-001: installed managed package with no detected usage
What triggers it. An installed managed package whose components (objects, fields, classes, flows) have no detected inbound reference from your own metadata.
Why it matters. A managed package nothing uses is review surface, license cost, and an attack surface with no offsetting value. Unused packages are also a common source of forgotten Connected Apps and OAuth grants. Confirming a package is genuinely unused before removal is far cheaper than discovering a hidden dependency after uninstall.
How to fix. Confirm there is no runtime-dynamic dependency on the package (a dynamic invocation, a hard-coded namespace in a SOQL string, an external integration that calls package endpoints), then plan the uninstall in a sandbox. If a dependency is real but dynamic, record it so the package stops appearing as unused.
SF-PKG-DEP-002: orphan managed component
What triggers it. A component that belongs to an installed managed package and is referenced by your metadata, but whose package or related package components are no longer fully present, leaving the reference dangling.
Why it matters. An orphan managed component signals a package upgrade or partial uninstall that left your metadata pointing at something that no longer fully exists. These dangling references fail at deploy or at runtime and are easy to miss because the component looks present in isolation.
How to fix. Reconcile the package state: complete the upgrade, reinstall the missing package components, or remove your metadata's reference to the orphaned component.
Reading the output
Governance findings carry the component type and API name, the owner
(or its absence), and the relevant date for review-by findings. Package
dependency findings carry the package namespace, the publisher, and the
referencing or orphaned component list. Set VULKRO_SF_GOVERNANCE_FILE
in CI so the same policy is enforced on every run.