37401 strict mode validate a diff scoped strict typecheck gate to stop new non strict code landing on main

[nicobytes]

This pull request adds a comprehensive feature specification document for a "diff-scoped strict typecheck gate" in the core-web workspace. The spec outlines the motivation, user scenarios, requirements, measurable outcomes, and legacy considerations for implementing a TypeScript strict-mode gate that only blocks new type errors introduced in a pull request, rather than all existing debt. The goal is to prevent new non-strict code from landing on main while a broader migration is still pending.

Key additions and themes:

Specification and Problem Framing

• Introduces a detailed problem statement explaining why a diff-scoped strict typecheck gate is needed, focusing on the challenges of partial strictness and the ongoing migration effort.
• Clearly defines the research question: whether it is feasible to block only new strict-mode violations in changed files, decoupling debt prevention from the full migration timeline.

User Scenarios and Acceptance Criteria

• Outlines four user stories (with priorities), including ensuring the gate catches new debt, avoids false positives, supports measured operating decisions, and produces a durable, actionable write-up. Each story includes independent tests and acceptance scenarios.
• Lists edge cases to ensure robustness, such as handling deleted files, shared configs, unmapped files, and shallow checkouts.

Functional Requirements and Success Criteria

• Specifies functional requirements for the evaluation harness, covering file detection

This PR fixes: #37401

[Copilot]

🟡 Changes recommended

The new spec contains an internally inconsistent/incorrect workspace project count (“22 of 55”), which should be corrected to match the current Nx project count.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Adds a spike spec document for evaluating a diff-scoped TypeScript strict-mode typecheck gate in the core-web Nx workspace, aimed at blocking new strict-mode violations without forcing a full workspace migration up-front.

Changes:

• Introduces a detailed problem statement and motivation for a diff-scoped strict typecheck gate.
• Defines user stories, acceptance scenarios, edge cases, functional requirements, and measurable success criteria for the spike.
• Captures dotCMS-specific legacy considerations and assumptions to guide the spike’s outcome and handoff.

File summaries

File	Description
specs/37401-diff-scoped-strict-typecheck-gate/spec.md	New spike spec defining goals, requirements, validation plan, and success criteria for a diff-scoped strict typecheck gate

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[claude]

Claude finished @nicobytes's task in 45s —— View job

---

Code Review

• Read the changed spec file
• Verify the Nx project count and strict opt-in numbers against the workspace
• Post review

This PR adds a single documentation file (specs/37401-diff-scoped-strict-typecheck-gate/spec.md, +408). No code, so the review focuses on factual accuracy and internal consistency.

I verified the numbers against the workspace:

Claim in spec	Verified count
project configs (denominator)	56 (project.json under core-web/{apps,libs})
strict: true opt-ins	22 ✅
strictTemplates: true	30 ✅
strictTemplates: false (apps)	4 ✅

New Issues

• 🟡 Medium: specs/37401-diff-scoped-strict-typecheck-gate/spec.md:18 — Internal inconsistency in the project count. Line 18 states "22 of 55 project configs opt back in locally", but the workspace has 56 Nx projects, and the same spec already uses the correct figure on line 208 ("the affected-project calculation expands to all 56 projects"). The denominator on line 18 should be 56. This confirms Copilot's finding. Fix this →

Everything else in the spec is internally consistent and the other quantitative claims (22, 30, 4) match the workspace. The document is otherwise well-structured — clear problem framing, prioritized user stories with independent tests, measurable success criteria, and an explicit out-of-scope section.

I did not make the edit since this is a review request. If you'd like, reply and I'll push the one-word fix.
· nicobytes/37401-strict-mode-validate-a-diff-scoped-strict-typecheck-gate-to-stop-new-non-strict-code-landing-on-main