[dmealing]

Summary

FR-023 Phase 2 slices S4 and S5 (#482): a Spring app loads a shared model's committed snapshot at runtime, and metaobjects:verify gains a dependency-drift mode in Java and Kotlin.

• S4, Spring runtime. metaobjects:generate ships .metaobjects/deps.lock.json and .metaobjects/deps/** on the classpath (config.json is deliberately not shipped). When classpath:.metaobjects/deps.lock.json exists, the Spring application loader loads each snapshot before the configured sources, with the same imported-is-load-only scoping and the same error codes as the build-time path (ERR_DEPENDENCY_SNAPSHOT_STALE, and ERR_DEPENDENCY_PACKAGE_NOT_OWNED raised after the loader's own errors). An app with no metadata of its own still loads its snapshot. With no lock and nothing declared, behaviour is unchanged; a classpath config that declares dependencies with no lock fails boot as stale.
• S5, verify. mvn metaobjects:verify -Dmeta.verify.mode=deps is the Java/Kotlin counterpart of meta deps check: current / drifted / unresolved (missing path, bad manifest, hash mismatch, or not yet in the lock). drifted and unresolved fail with ERR_DEPENDENCY_UPSTREAM_DRIFT. It resolves the path transport only, loads no model and writes nothing. It is opt-in and not part of the default gate set, because it needs the publisher reachable.
• The Node meta deps sync stays the only writer of snapshots and the lock. Kotlin uses the same Maven goal and loader.

New public API in metadata: Dependencies.check, Dependencies.SnapshotReader, DependencySet.ofSnapshot, and a MetaDataLoader.fromUris overload that takes a DependencySet.

Tests

• The shared expectCheck corpus arm runs in Java (DependencyCheckConformanceTest), and the resolution and load-error arms run again through the Spring runtime's classpath reader (DependencySnapshotRuntimeConformanceTest).
• Spring boot tests cover: an entity extending an imported node, an app with no metadata of its own, no lock (unchanged), a stale or missing snapshot, a config declaring dependencies with no lock, a lock entry the config no longer declares, and a node declared into a dependency's package.
• NodeSyncedDependencySnapshotTest consumes a lock and snapshot written by the real Node meta deps sync.
• maven-plugin tests cover the deps mode and the resource registration.
• Local java and gates lanes were green. One unrelated 5s site test timed out under heavy machine load and passed on rerun.

Validation

• 1 no-mistakes run was used. Review, test, document, lint and push passed. The PR step then hit a transient GitHub GraphQL error, so this PR was opened by hand from the pushed head with no new commit.
• CI was skipped (--skip ci).
• Review found two issues, both fixed by the pipeline: an app with no metadata of its own skipped the snapshot load, and Dependencies.check read the artifact twice.
• Decision on test-1: the live check was inconclusive (the Spring and corpus scenarios are covered by automated tests rather than a standalone running product). It was accepted once the uncovered scenarios each had a passing automated test, which added the lock-entry-not-declared Spring case and the Node-synced end-to-end test.
• Decision on agent-context-verify-tables: teaching the deps verify mode in agent-context/skills (the verify skill table, the audit Java/Kotlin references and the capability sheet, with their pinned fixture copies) is deferred to slice S10, which updates them together.

Out of scope

Publishing (S8), C# (S7, S9), the maven/nuget transports in the Node sync, and the S10 close-out doc rewrite.