The root dependency graph is unlocked, so nothing can audit it

There is no committed root `Gemfile.lock` — `.gitignore` ignores every one — while `.github/dependabot.yml` treats the root lockfile as the single authority for every dependency. Dependabot and any SCA tooling therefore reason about a graph that does not exist, and clean developer and CI installs resolve a different graph over time.

The `Gemfile` follows Rails `main` for three packages and leaves development dependencies floating, so the drift is not hypothetical. For the assessment only, a temporary lock resolved Rails `main` to `64be779e853ae94e06803c82c6fdef9b2e31f65c`; that is evidence of the graph examined on 2026-08-22, not a value to commit.

The practical consequence is that we cannot answer "what was in the build" for any past CI run or release, and no vulnerability scan of ours covers transitive dependencies.

## Fix direction

- Commit the root lockfile and pin unreleased Rails to an exact revision.
- Use frozen installs in CI and in deployment.
- Keep a separate, explicitly mutable compatibility lane for the "latest everything" signal we lose by locking.
- Generate SBOM and vulnerability scans from the locked graph.

The generated cell image has the same defect for its own bundle; that half is tracked with the image work under `HC-PT-011`.

`HC-PT-010` of the purple-team assessment of 2026-08-22, rated Medium.

Start by reading Gemfile, .gitignore, and .github/dependabot.yml to confirm how the root dependency graph is currently resolved and monitored. Then inspect the existing CI and deployment configuration for install behavior. Done means the root lockfile and exact Rails revision are committed, production paths use frozen installs, a separate mutable compatibility lane remains, and scans generate SBOM and vulnerability results from the locked graph.

Written by the indexing model from the issue text.