Class AgentRunner

Checks whether the serialized content for a new artifact version is identical to the latest existing version of the same artifact, using SHA-256 content hashing.

When the content is unchanged, creating a new version adds noise without value. This method computes the hash of the candidate content and compares it against the ContentHash stored on the most recent version (populated by MJArtifactVersionEntityServer.Save()).

Creates a ConversationDetailArtifact junction record linking an artifact version to a conversation detail, then returns the standard artifact result tuple.

Extracted as a helper so both the normal version-creation path and the duplicate-skip path can share the same linking and return logic.

Vets one rung of the version-target ladder, returning the plan with a normalized id when the target is usable and null when the caller should fall back.

Three things are checked, in cost order:

1. Shape. The id must be a UUID-shaped string. This matters because it is interpolated into the ExtraFilter fragments built by GetMaxVersionForArtifact and CheckForDuplicateVersion; those escape what they are handed, but an id that is not a UUID cannot name an artifact, so rejecting it here turns a doomed query into a clean fallback. The id is then TRIMMED for downstream use — IsValidUUID tolerates surrounding whitespace, so a value with a trailing newline passes validation and would otherwise reach ArtifactID='<uuid>\n' and fail as a SQL conversion error.
2. Existence — directive-named targets only.
3. Authorization — directive-named targets only. vwArtifacts carries no per-user predicate and no row-level-security filter, so a row loading successfully proves only that it EXISTS. Without this check an agent could name any artifact id in the instance and have the run's payload appended to it as a new version. The caller must own the artifact or hold an explicit CanEdit grant on it.

Existence and authorization resolve in ONE RunViews round trip, and via RunView rather than BaseEntity.Load deliberately: Load THROWS on a permission denial, a SQL conversion error or any transient DB fault, and a throw here would propagate to the method-wide catch and lose the whole artifact — the opposite of the graceful fallback this is meant to provide.

A caller-supplied sourceArtifactId is shape-checked but NOT loaded or authorized: it is a server-side argument rather than model output, and adding a round trip plus a new denial mode to that path would change behavior for every existing agent. (The pre-existing exposure on that path — any authenticated caller may name any artifact id — is unchanged by this PR and wants its own fix.) One exception, and it is deliberate rather than incidental: if the agent named the SAME id first and it failed authorization, rejectedIds refuses it on the caller rung too. The caller path still performs no authorization of its own; it just cannot be used to launder an id this run has already refused.

Why this does not call PermissionEngine / ArtifactPermissionProvider. That provider (MJCoreEntities/src/custom/PermissionProviders/ArtifactPermissionProvider.ts) answers "may this user Update this artifact" from the permission ROWS, and is the right home for that question in general — see guides/UNIFIED_PERMISSIONS_GUIDE.md §1. It is not used here for two reasons specific to this path. First, it answers only half the question: it reads grant rows and does not treat the artifact's OWNER as an editor, so the UserID check below would remain regardless and the owner half would still live in two places. Second, and decisive: PermissionEngine.CheckPermission returns Allowed: false with "Unknown permission domain" when its domain is not loaded, and this path's response to a denial is a SILENT fallback to creating a new artifact. A deployment that has not synced metadata/permission-domains — or any caller that reaches the runner before PermissionEngine.Config() — would therefore stop versioning for every legitimate editor, with nothing in the logs to say why. A direct query has no such dependency on engine state. As of this writing nothing server-side calls PermissionEngine or runs its Config(): its callers are Explorer's Permissions dashboard, the Sharing Center, and the integration test suite. (Lists/server, Communication/notifications and the MJCoreEntities entity extensions call ResourcePermissionEngine, a different class over MJ: Resource Permissions.)

The cost of that choice is drift: this is a third answer to "can this user edit this artifact", alongside the provider and ng-conversations' artifact-permission.service.ts. If artifact sharing grows a new grant shape — role grantees, SupportsDeny, cascade from collections — this method must be updated with the provider. Revisit the delegation once PermissionEngine is routinely configured server-side. The cleaner precondition is upstream: CollectionPermissionProvider already treats a collection's owner as a synthetic full-access grantee, and the same treatment in ArtifactPermissionProvider would make it a complete answer, at which point this method should delegate to CheckPermission(..., 'Update') outright rather than compose an owner check around it.