fix(AGENT-679): enable TypeScript type-checking in CI and next build

[maxtechera]

Summary

• Fix all 162 TypeScript errors across ~59 files in apps/web/, packages-answers/ui/, and packages-answers/utils/
• Set ignoreBuildErrors: false in apps/web/next.config.js
• Add tsc --noEmit step to .github/workflows/main.yml (NodeCI)
• Add typecheck script to apps/web/package.json

Context

Discovered after AGENT-678 shipped a ReferenceError: isFilterExpanded is not defined to production — an error that tsc would have caught at build time. Root cause: no TypeScript type-checking was running anywhere in the pipeline.

Test plan

• Verify pnpm --filter web tsc --noEmit passes with 0 errors
• Verify pnpm --filter web build passes (next build now checks types)
• Verify CI workflow runs the new typecheck step on PRs

Linear: https://linear.app/answeragent/issue/AGENT-679

[linear]

AGENT-679 Enable TypeScript type-checking in CI and apps/web build

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
answerai-docs	Building	Preview	Feb 11, 2026 8:06pm
the-answerai	Building	Preview	Feb 11, 2026 8:06pm

[claude]

PR Review: fix(AGENT-679): enable TypeScript type-checking in CI and next build

Summary

This PR addresses a critical production issue where TypeScript errors weren't caught during build time, leading to a ReferenceError in production (AGENT-678). The changes fix 162 TypeScript errors across 59 files, enable type-checking in both Next.js builds and CI, and add proper tooling to prevent future type-related issues.

---

Positive Aspects ✅

Critical Infrastructure Improvements

1. CI Integration (.github/workflows/main.yml:63-64): Added pnpm --filter web tsc --noEmit step - essential for preventing production issues
2. Next.js Build Config (apps/web/next.config.js:66): Changed ignoreBuildErrors: false to enable type-checking during builds
3. Package.json Script (apps/web/package.json:10): Added typecheck script for manual type-checking
4. Type Declarations (apps/web/react-markdown.d.ts): Created proper type declarations for react-markdown library

---

Critical Issues 🚨

1. Overuse of Type Assertions (as any)

Impact: HIGH - Defeats the purpose of TypeScript type-checking
Count: 62 instances throughout the codebase

Problem: Using as any silences TypeScript errors but doesn't fix underlying type issues. This creates a false sense of security - the type system can no longer catch bugs at these locations.

Recommendation: Define proper types for Chat, Message, Session entities instead of bypassing type system with as any.

2. Existing Types Not Utilized

Impact: MEDIUM - Missed opportunity for type safety

Looking at packages-answers/ui/src/types/index.ts, there are existing types like Message, AgentReasoning, SidekickListItem that should be used instead of as any casts.

3. @ts-ignore Comments (7 instances)

Impact: MEDIUM - Technical debt accumulation

Comments like "@flowise/components types not available in this context" suggest module resolution issues that should be fixed properly rather than suppressed.

---

Recommendations Summary

Must Fix Before Merge (P0)

1. Reduce as any usage: Define proper types for the most common entities (Chat, Message, Session)
2. Fix @flowise/components imports: Resolve module resolution issue properly
3. Verify CI fails on type errors: Test that CI step actually catches issues

Should Fix Soon (P1)

4. Create proper type definitions: For all entities currently cast to any
5. Document type-checking process: Add to CLAUDE.md
6. Track technical debt: Create follow-up tickets for remaining as any usages

Nice to Have (P2)

7. Add pre-commit hook: Run tsc --noEmit locally
8. Type coverage metrics: Track properly typed code percentage

---

Conclusion

Overall Assessment: ⚠️ Approve with conditions

The infrastructure changes are excellent and critical - they should be merged to prevent further regression. However, the implementation approach creates significant technical debt that undermines TypeScript's value.

Suggested Path Forward:

1. Merge this PR to get CI infrastructure in place ✅
2. Create follow-up tickets to properly type the codebase section by section
3. Establish team agreement: new code must use proper types, not as any
4. Consider a "type cleanup sprint" to address the 62 instances of as any

This is a necessary first step, but 62 instances of as any means we're checking the box of "zero type errors" without achieving actual type safety.

---

Review conducted using repository's CLAUDE.md guidelines and TypeScript best practices.