feat(core-domain): GT-377 AC-3 — ESLint stateless-Core *Repository guard + CI gate

[beyondnetPeru]

GT-377 AC-3 — ESLint stateless-Core *Repository guard, enforcing + CI-gated

Closes the AC-3 acceptance criterion of GT-377: "ESLint boundary guard fails CI if a *Repository for product/initiative/evidence/decision appears."

What this delivers

• Guard (flat config, ESLint 9): packages/core-domain/eslint.config.mjs bans Identifier[name=/(Product|Initiative|Evidence|Decision)Repository/] via no-restricted-syntax. Core is a stateless Evaluation Engine — those are context, not entities (ADR-0101). Entity-scoped, so legit infra repos (AuditRepository, createRepository, …) are untouched.
• Single source of truth: the rule lives in packages/core-domain/eslint.guards.cjs, imported by both the config and the test.
• Negative regression test: src/evaluation/stateless-core-repository.guard.spec.ts — 14 cases proving the guard fires on all four banned entities (import + inline interface) and never on legit *Repository.
• CI gate: new Run core-domain architecture boundary guard (GT-377) step in .github/workflows/ci-cd.yml (test-core-domain). Before this PR, grep lint:boundaries .github/workflows = 0.
• Migrated off the ESLint-9-incompatible legacy .eslintrc.js + --no-eslintrc (deleted the dead file); lint:boundaries script → eslint "src/**/*.ts".

Root cause of the long-standing "lint:boundaries broken" note

It was not the boundaries plugin. The root package.json global override "ajv":"8.17.1" conflicts with the workspaces' direct ajv:8.20.0 (EOVERRIDE), so under --legacy-peer-deps npm silently dropped all ajv overrides and collapsed ajv@8 onto eslint/@eslint/eslintrc (which need ajv@6), making ESLint's loader throw missingRefs / Cannot set properties of undefined (setting 'defaultMeta').

Fix: scoped overrides — ajv aligned to 8.20.0 (== direct dep, no conflict) + carve-outs eslint/@eslint/eslintrc → ajv@^6.12.6.

⚠️ Touches shared root files — merge-order note for the SDLC closing thread

• package.json (overrides) and package-lock.json (root).
• The lockfile change is scoped to the eslint subtree (~82 lines, nested ajv@6.15.0, no cross-workspace drift), produced incrementally and verified under npm ci.
• High risk of lockfile conflict with the sibling integration branches feat/core-gt377-schemas (AC-1), feat/core-gt379-blueprint-deployment, feat/core-gt382-wasm-path if they also touched the lockfile. Recommend: merge sequentially and reconcile the lockfile at the end with the incremental method (remove only the eslint/@eslint/eslintrc entries from the lockfile + node_modules, then npm install --legacy-peer-deps) — never rm package-lock.json (full re-resolution drifts ~1300 lines, e.g. @types/node 24→26).

GT-377 status

• AC-2 (types/binding) already MET (prior wave); AC-3 MET here.
• AC-1 (schemas) is open in feat/core-gt377-schemas — once it lands, GT-377 → DONE. Left as IN-PROGRESS.
• Gap board + catalog updated (EN/ES).

Verification

npm ci → npm run lint:boundaries --workspace @evolith/core-domain = 0 errors; tsc build green; core-domain 692/692 tests; injected ProductRepository correctly fails the guard, AuditRepository does not.

Follow-up (chip filed)

packages/mcp-server and apps/core-api carry the same broken lint:boundaries (--no-eslintrc -c .eslintrc.js), ungated by CI — same migration pattern applies.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 4ea76378c7

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Declare the ESLint config's typescript-eslint dependency

When @evolith/core-domain is installed or linted in isolation, this new flat config imports the typescript-eslint meta-package even though packages/core-domain/package.json only declares @typescript-eslint/parser; the package is currently present only because another workspace (apps/core-api) happens to depend on it. A focused workspace install or future removal from that unrelated package will make npm run lint:boundaries --workspace @evolith/core-domain fail with ERR_MODULE_NOT_FOUND before the boundary guard can run, so core-domain should declare typescript-eslint directly or avoid importing it.

Useful? React with 👍 / 👎.