From e793d9476b61329c94b465ab6b14c79d48d46451 Mon Sep 17 00:00:00 2001 From: ced4568 Date: Tue, 18 Aug 2026 13:50:38 -0500 Subject: [PATCH] docs(deps): document the dependency-lock convention MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Was ambiguous — backend/frontend committed lockfiles, api/gateway/provisioner didn't, with no stated reason either way. Now explicit: every first-party Node service commits its package-lock.json, validated with npm ci before each commit that touches it. --- docs/ENGINEERING_SOP.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/docs/ENGINEERING_SOP.md b/docs/ENGINEERING_SOP.md index e2a9d49..0a67c53 100644 --- a/docs/ENGINEERING_SOP.md +++ b/docs/ENGINEERING_SOP.md @@ -233,3 +233,16 @@ Full design: `docs/PHASE3A_IDENTITY_AND_INSTRUCTOR_ACCESS.md`. Operational refer scoping, CSRF, rate limiting, password change, and audit logging. - **Known limitations, future OIDC path, production HTTPS expectations:** see `docs/PHASE3A_IDENTITY_AND_INSTRUCTOR_ACCESS.md` §15–17. + +## 11. Dependency lock convention + +Every first-party Node service commits its `package-lock.json`: `backend/`, `frontend/`, +`platform/api/`, `platform/gateway/`, `platform/provisioner/`. This wasn't consistently true +before Phase 3B — `platform/api/`'s lockfile existed locally but was never committed, and +`platform/gateway/`/`platform/provisioner/` never had one generated at all. Neither was a +deliberate policy; both were oversights, fixed in Phase 3B (`chore(deps)` commits). + +Going forward: after any `npm install` that changes a service's dependencies, the updated +`package-lock.json` is part of the same commit as the `package.json` change — never left +untracked, never regenerated-and-ignored. Validate a lockfile actually matches its +`package.json` with `npm ci` (fails loudly on drift) before committing either.