resolve-governances

name	resolve-governances
description	Partial Skill: invoke by name only — the SDD governance matcher, resolving which actor-bar governances apply to a touched file — run by the conductor and the cold spec/impl judges, not triggered by users directly.
user-invocable	false
metadata	{"internal":true}

Resolve Governances

The concrete engine for SDD governance resolution. For a touched file's artifact-type it names, per production-chain role, which agent runs it and which resolved-actor bar candidates it loads — matching governances across the caller-passed project anchors, the matched plugin squad (from the project registry .agents/universal-plugin.json), and the sdd defaults. It is a dumb matcher: it returns each bar's candidates bucketed by tier and does not order by precedence or apply compose — the consuming agent composes. The conductor and the cold judges run it so they never hand-enumerate the bars. It carries a self-contained .mts script (the repo's node-≥23.6 / no-deps convention).

Run the resolution

node "<skill>/scripts/resolve-governances.mts" --root . --artifact-type <type> --project <path> [--project-root <path>]

• --root is the registry location (default .) — .agents/universal-plugin.json.
• --project <path> is the file's own project anchor (defaults to --root); --project-root <path> is the outer shared layer in a monorepo (omit for a single-project repo). Anchors are caller-passed, never discovered — the conductor knows the project from discover-specs' project-path or context.
• --artifact-type <type> emits the per-role plan as JSON: each role carries its resolved agent and the resolved-actor bars only. Each bar's candidates are bucketed by tier — project / project-root (direct-read file paths) and plugin / sdd (<plugin>:<bar> / sdd:<name> harness-load refs). The fixed-universal governances are invariant per role and stay declared in the role/agent definition — the matcher does not emit them.
• --path <file> (no --artifact-type) consults the optional tiebreaker map .agents/sdd/artifact-types.toml; a no-match prints a classify-by-convention note.
• No --artifact-type and no --path → validates the registry is well-formed + unambiguous (governance registry OK, or per-line violations).

When node is absent, an agent performs the same matching by hand: read the registry, match each touched file's artifact-type to a squad, and name each role's agent + bar candidates per tier.

Boundaries

It owns no lifecycle state and writes nothing — it names candidates; the consuming agent loads each (direct-read for project files, harness-load for plugin/sdd skills), reads each governance's own compose, and composes by precedence sdd-default < plugin < project-root < project (most-specific wins; replace supersedes). Registry matching is deterministic; disambiguating an artifact-type claimed by two plugins is the consumer's agentic step (the plan returns status: needs-input).