# ES skill set — follow-up work (deferred, planned for next session)

Context: a 2026-07-27 audit of five repos (`chat-service`, `lms-service`, `webapp-v1`, `admin-panel`, `lms-webapp`) found real drift between the ES skills and what's actually shipped. First pass (done) added a new `deployment-infrastructure` skill and rewrote `backend-architecture` to make the NestJS standalone-service shape a first-class prescribed standard, matching chat-service/lms-service. `proxy-infrastructure`, `api-design`, `auth-infrastructure`, and `testing-strategy` were only updated with "field notes" documenting the drift as observed variance — they don't yet mandate a single winning convention. That's the work below.

**Before doing any of this**: verify the plugin update already made (`~/.claude/skills/engineering-system/` — new `deployment-infrastructure/SKILL.md`, rewritten `backend-architecture/SKILL.md`, updated top-level `SKILL.md`/`README.md`, `plugin.json` bumped to 0.4.0). Run `/reload-plugins` or start a fresh session to load it, and confirm it reads the way you want before layering more changes on top.

## 1. Pick one response envelope and mandate it (`api-design`)

Currently two shapes coexist for real: `{success, message, data, error}` (chat-service) vs `{success, statusCode, data}` (lms-service, lms-webapp). Decide which one is the ES standard going forward, then update `api-design/SKILL.md` to state it as a hard requirement rather than "known variance" — and note in the skill that existing services using the other shape are a known migration debt, not a second valid option.

## 2. Pick one API versioning style and mandate it (`api-design`)

Currently: global `app.setGlobalPrefix('api')` with no version segment (lms-service) vs. version baked into each controller's literal path (`auth/v1`, `chat/v1`, chat-service). Decide: single global `/api/v1/` prefix via framework versioning, or per-controller literal versioning. Whichever is chosen, also add the rule that prevents the route collision the audit found (two controllers registering the identical literal path, silently resolved by registration order) — e.g. require a namespace/path review before adding a new controller base path.

## 3. Make `proxy.ts` mandatory, not just recommended (`proxy-infrastructure`)

None of the three audited Next.js frontends had a `proxy.ts`/`middleware.ts` at all — auth gating was done ad hoc in route handlers or (in admin-panel) a client-side guard component that turned out to only check `isAuthenticated`, never `role`. Decide whether every new ES Next.js project must ship a `proxy.ts` from day one (even a minimal one that just does the optimistic auth redirect), and if so, add that as a required item in the project scaffolding / `feature-contract` checklist, not just a "here's what good looks like" description.

## 4. Also still open from the original scope discussion

- `frontend-architecture` was explicitly left out of scope in the first pass. The audit found feature-folder shapes vary inconsistently against ES's own canonical `components/hooks/model/api` (e.g. lms-webapp's `courses` feature uses `lib/` instead of `hooks/`, `payments` has no `components/`/`hooks/` at all). Decide if this needs the same "pick one and mandate it" treatment or if the variance is acceptable case-by-case.
- Consider whether the leaner Docker build (`output: "standalone"` + `turbo prune`) noted as an "optional future improvement" in `deployment-infrastructure` should be promoted to required once one project actually adopts it, so it doesn't just stay a suggestion forever.