feat(reporting-governance): add profile artifact binding slice

docs/architecture/agent-reporting-governance-plugin.md

@@ -177,7 +177,59 @@ This matters architecturally because it proves the plugin can:
 - preserve honest delivery semantics instead of collapsing `dispatched` into false success
 - provide a migration path from repo scripts toward package-level adapters and deployment profiles
 
-The mainline next step is therefore not “more watchdog patching,” but formalizing this runtime composition inside the plugin’s adapter and capability model so future package extraction has a stable target.
+## Compatibility envelope and legacy compatibility mode
+
+The architecture now draws a hard line between two caller postures:
+
+### Compatibility envelope
+
+A caller is inside the compatibility envelope once it supplies either:
+
+- a deployment profile / profile artifact, or
+- a package version pin
+
+Inside this envelope, runtime compatibility is enforced against the descriptor as a truth contract:
+
+- canonical schema paths must match
+- requested plugin version must be declared compatible
+- required capability expectations must be satisfied
+- requested actions must be supportable or honestly degraded
+
+If not, the system fails closed before producing a runnable enforcement contract.
+
+### Legacy compatibility mode
+
+Legacy compatibility mode exists only so older callers that still invoke package core without profile/package metadata do not break immediately.
+
+Behavior in this mode:
+
+- no version pin is assumed
+- schema mismatch is surfaced in `schema_checks` but does not hard-fail by itself
+- preflight records migration debt as notes
+- truth semantics for actual planning are still preserved
+
+This is a migration concession, not a long-term steady state.
+New callers should move to profile/package-backed invocation.
+
+## Minimal package profile artifact trajectory
+
+Architecture is also now advanced one notch from “profiles are external YAML docs” toward “profiles are package artifacts with a loader boundary”.
+
+Current minimal slice:
+
+- package-owned profile artifact snapshot: `plugins/reporting-governance/profiles/strict-manager-mode.profile.json`
+- package loader: `src/storage/profile-artifact.mjs#loadDeploymentProfileArtifact(...)`
+- binding contract projector: `src/storage/profile-artifact.mjs#createDeploymentBindingContract(...)`
+
+Architectural meaning:
+
+- package can carry one portable profile artifact under its own boundary
+- storage layer owns loading/package-artifact interpretation
+- runtime binding can be derived from the artifact rather than hardcoded entirely in docs
+- tests prove the artifact resolves into concrete script and runtime-artifact paths
+
+This is intentionally still a **minimal verifiable slice**, not the full deployment system.
+It proves the package boundary can own profile artifacts and bind them into runtime execution inputs.
 
 Primary follow-on specs: