feat(committees): add committee detail shell with overview tab and BFF endpoints

[manishdixitlfx]

Summary

• Add committee detail shell with tabbed layout (overview, members, votes, meetings, surveys, documents)
• Add overview tab with leadership, membership stats, and key topics
• Add BFF endpoints for votes (with fallback), meetings, surveys, join/leave, and my-committees
• Wire settings tab with committee configuration display
• Wire meetings tab with upcoming/past meeting views
• Wire votes tab with paginated table and results drawer
• Wire members tab with full CRUD, search/filter, and governance fields
• Add leadership dialog for assigning/removing chair and co-chair
• Add committee create/edit form enhancements
• Add surveys tab placeholder (content in separate PR)

Endpoints added

Method	Route	Description
GET	/committees/my-committees	User's committees with role
GET	/:id/votes	Committee votes (with vote-type fallback)
GET	/:id/meetings	Committee meetings
GET	/:id/surveys	Committee surveys
POST	/:id/join	Self-join open committee
DELETE	/:id/leave	Leave committee

Existing CRUD endpoints (committees, members, settings) were already present.

Test plan

• Navigate to a committee → detail shell loads with tabs
• Overview tab shows leadership, membership stats, key topics
• Members tab shows filterable member list with add/edit/delete
• Votes tab shows paginated votes with status filter and results drawer
• Meetings tab shows upcoming/past meetings with filter toggle
• Settings tab shows committee configuration (PMO only)
• Leadership dialog assigns/removes chair and co-chair
• Join/leave committee works from overview
• BFF endpoints return correct data

LFXV2-1218

🤖 Generated with Claude Code

[niravpatel27]

Silent error swallowing — All console.error calls were removed from error handlers here (and in several other places in this file) but no replacement logging or telemetry was added. If there's a global HTTP error interceptor that handles this, this is fine — but if not, debugging production issues will be very difficult since errors are silently discarded. Please verify centralized error handling covers these cases, or consider keeping at minimum a structured log call.

[niravpatel27]

Hardcoded page_size of 100 may silently truncate results — The TODO acknowledges this, and the warning log is a good safety net. However, for committees with heavy vote activity, users will see incomplete data with no indication in the UI. Consider either:

1. Implementing cursor-based pagination to fetch all results
2. Surfacing a "showing first 100 votes" indicator in the UI
3. At minimum, bumping this to a higher limit with a follow-up ticket to paginate properly

[niravpatel27]

Deleted committee-application.interface.ts — This removes CommitteeJoinApplication and CreateCommitteeJoinApplicationRequest types and their barrel export. Please verify nothing else in the monorepo or downstream consumers imports these types. If they were genuinely unused, this cleanup is fine — but if any other package or branch (especially the stacked PRs) references them, this will break.

[MRashad26]

Re-review — 8 inline findings (2 original unresolved + 6 new)

[MRashad26]

[Original #1 — still present] Record<string, any> instead of typed query params

Per development-rules.md: "Use TypeScript types and interfaces for all data". There are 5 occurrences of Record<string, any> across this PR for query params. Define typed interfaces instead:

interface CommitteeMeetingQuery { page_size?: number; page_token?: string; order_by?: string; }
interface CommitteeSurveyQuery { page_size?: number; status?: string; }

This applies to both getCommitteeMeetings and getCommitteeSurveys signatures, as well as the controller callsites.

[MRashad26]

[Original #9 — not addressed] getCommitteeVotes() is dead code — never called from any component

The BFF exposes GET /committees/:id/votes and this client method calls it. However, committee-votes-list.component.ts completely ignores both and instead calls voteService.getVotesByProjectPaginated() + voteService.getVotesCountByProject() with a committee_name filter.

This means:

• This method is unreachable dead code
• The BFF getCommitteeVotes endpoint is also unreachable
• Two different filtering strategies exist (server: committee_uid tag, client: committee_name filter)

Either wire the component to use this method (and the BFF endpoint), or remove both.

[MRashad26]

[New #1] votes_for assigned total responses — misleading data

The fallback vote mapping assigns ALL responses as affirmative:

votes_for: totalResponses,
votes_against: 0,
votes_abstain: 0,

This makes the UI show 100% approval for every vote. The comment says "so UI progress bars reflect the real response count instead of showing misleading zeros" — but showing 100% approval is equally misleading.

Consider either:

1. Exposing total_responses without pretending they're all affirmative
2. Adding a breakdown_available: false flag so the UI can render a "breakdown unavailable" state instead of fake vote counts

[MRashad26]

[New #2] Silent error swallowing across multiple layers

This catch returns [] with a logger.warning — meaning upstream 500 errors are silently converted to empty results. The same pattern exists in getCommitteeMeetings (returns { data: [] }). Combined with client-side catchError(() => of([])) in committee-surveys-list and committee-votes-list, errors are swallowed at every layer.

The user sees an empty state with no error indication. The surveys list at least has a loadError signal — votes list doesn't.

At minimum, the BFF should propagate 5xx errors (only catch 4xx gracefully). Let components decide how to handle errors rather than hiding them.

[MRashad26]

[New #3] Record<string, any> in survey service — same typing issue

public async getCommitteeSurveys(req: Request, committeeId: string, query: Record<string, any> = {}): Promise<Survey[]> {

Same as the committee service — should use a typed interface for the query params instead of Record<string, any>.

[MRashad26]

[New #5] Unsafe req.query passthrough — parameter injection risk

const surveys = await this.surveyService.getCommitteeSurveys(req, id, req.query as Record<string, any>);

In the survey service, req.query is spread into the upstream params:

const params = { ...query, type: 'survey', tags: `committee_uid:${committeeId}` };

Since query is spread before type and tags, a request like ?type=user&tags=admin would be overridden — but query can still inject arbitrary params that get passed upstream (e.g. ?page_size=999999).

The getCommitteeMeetings service correctly whitelists allowed params. Apply the same pattern here:

const allowedParams = ['page_size', 'page_token', 'status'];
const sanitized: Record<string, string> = {};
for (const key of allowedParams) { if (query[key]) sanitized[key] = String(query[key]); }

[MRashad26]

[New #6] Page truncation logged but silently returned

if (voteResources.length >= 500) {
  logger.warning(req, 'get_committee_votes', 'Vote results may be truncated...');
}

Logs a server warning but returns the truncated data without any indication to the client. The UI will show the first 500 votes as if that's the complete set.

Consider returning a truncated: true flag in the response, or implementing cursor-based pagination (the TODO comment at line 415 acknowledges this). At minimum, add a response header or metadata field so the client can show a "showing first 500 results" notice.

[MRashad26]

[New #8] Component bypasses dedicated BFF endpoint — creates dead code and dual strategies

This component calls voteService.getVotesCountByProject() and voteService.getVotesByProjectPaginated() with a committee_name filter. However, the BFF has a dedicated GET /committees/:id/votes endpoint (with fallback logic and committee_uid tag filtering), and the client has CommitteeService.getCommitteeVotes().

This means:

• BFF getCommitteeVotes is dead code (no caller)
• Client CommitteeService.getCommitteeVotes() is dead code (no caller)
• Server filters by committee_uid tag, but this component filters by committee_name string — different strategies that may produce different results

Either wire this component to use the dedicated committee votes endpoint, or remove the BFF endpoint and client method to avoid confusion.

[asithade]

Review — 13 findings

Good progress on the committee detail shell. The BFF endpoints, tab layout, and member form enhancements are well-structured. Flagging the items below for cleanup before merge.

See inline comments for details.

[asithade]

Dead code — createSurvey() is never called.

Problem: This method is defined but never referenced from the template or any other component.

Why it's a problem: Dead code adds confusion — future developers may assume it's wired up somewhere.

Fix: Either remove the method entirely, or if it's intended for a "Create Survey" button in the surveys tab, wire it to a button in committee-view.component.html with a click handler.

[asithade]

Leftover console.error.

Problem: handleCommitteeError still calls console.error here.

Why it's a problem: Every other error handler modified in this PR removed console.error in favor of toast-only feedback (e.g., createMemberOperation, the two error: () handlers above). Leaving this one creates an inconsistency and leaks error details to the browser console in production.

Fix: Remove the console.error line. The messageService.add() toast below already handles user-facing feedback. If server-side visibility is needed, the backend controller already logs the error.

[asithade]

Question: Was removing the lock icon (fa-light fa-lock) for private/non-public committees intentional? Previously there was an @if (!committee()?.public) block showing a lock icon next to the committee name here. It's been removed with no replacement or mention in the PR description.

[asithade]

Barrel import instead of direct path.

Problem: VOTE_LABEL is imported from @lfx-one/shared (barrel export) while all other imports in this PR and the codebase use direct paths like @lfx-one/shared/constants.

Why it's a problem: Project rules require direct imports for standalone components — no barrel exports. Barrel imports can also cause larger bundle sizes due to tree-shaking issues.

Fix: Change to import { VOTE_LABEL } from '@lfx-one/shared/constants'.

[asithade]

CommitteeLeadership is redundant, chair/co_chair don't exist upstream, and the dialog is dead code.

Problem (4 issues):
(a) The CommitteeLeadership interface (line 109) is a redundant subset of CommitteeMember — it has uid, first_name, last_name, email, organization, and an elected_date field that is just CommitteeMember.role.start_date renamed.
(b) Committee.chair and Committee.co_chair fields added here do not exist on the upstream committee service response. No server-side enrichment populates them, so they will always be undefined. Adding phantom fields to a shared interface that represents an API contract is misleading.
(c) The AssignLeadershipDialogComponent is never opened — no component calls dialogService.open(AssignLeadershipDialogComponent, ...).
(d) CommitteeUpdateData (line 277) also adds chair/co_chair, but the upstream PUT/PATCH endpoint doesn't accept them.

Why it's a problem: The shared Committee interface should match the upstream API contract. Adding fields the API never returns creates a false contract. The redundant CommitteeLeadership type and unused dialog add dead code.

Fix: Remove chair/co_chair from Committee and CommitteeUpdateData interfaces. Remove CommitteeLeadership interface and LeadershipRole type. Use CommitteeMember | null if a typed reference to the leader is needed — derive leadership at the component level by filtering the members list by role.name === 'Chair' / 'Vice Chair'. If the dialog is deferred to a follow-up PR, note that explicitly in the PR description and don't add the interface fields until the enrichment exists.

[asithade]

onDateChange() is redundant — Angular re-runs group validators automatically.

Problem: onDateChange() calls this.form().updateValueAndValidity() and is bound to (onSelect) on all four calendar inputs.

Why it's a problem: Angular's reactive forms already re-run group-level validators (including the dateRangeValidator registered on the FormGroup) automatically when any child control's value changes. The manual updateValueAndValidity() call is redundant.

Fix: Remove the onDateChange() method and remove all four (onSelect)="onDateChange()" bindings from the template. The date range validation will continue to work without them.

[asithade]

is_individual creates unnecessary complexity for a UI-only toggle.

Problem: is_individual is a UI-only form control that toggles whether the organization field is required/disabled. But organization was already optional (no validator) before this PR. This PR adds Validators.required to organization and then adds this checkbox + onIndividualToggle() + takeUntilDestroyed subscription to bypass that requirement — creating complexity to solve a problem it introduced. The field is never sent to the API; buildOrganizationPayload just checks it to return null.

Why it's a problem: It adds a form control, a valueChanges subscription, a toggle handler that enables/disables controls and swaps validators, and a MemberFormValue interface field — all for something the API doesn't know about. If "org is required unless explicitly individual" is a real business rule, it should come from the upstream API contract.

Fix: Clarify with product whether organization is truly required. If not, remove is_individual, remove Validators.required from organization, and let users simply leave it blank. If it is a real requirement, keep the validation but simplify — consider using a reactive disabled state driven by a signal rather than imperative enable/disable/clearValidators/setValidators calls.

[asithade]

Inline type literal should be a named interface.

Problem: This inline type { uid: string; name: string; status: string; end_time: string; committee_uid: string; num_response_received?: number; total_voting_request_invitations?: number; } is used as the generic param for proxyRequest<QueryServiceResponse<...>>.

Why it's a problem: Per project rules (component-organization.md, development-rules.md), all interfaces belong in @lfx-one/shared/interfaces, not inlined in service methods. Inline types are not reusable, not discoverable, and bypass the shared package convention.

Fix: Extract this into a named interface (e.g., VoteQueryResource) in packages/shared/src/interfaces/ and import it.

[asithade]

Client-side filtering is unnecessary — use tags for server-side filtering.

Problem: The fallback path fetches up to 500 votes for the entire project via parent: \project:${projectUid}`and then filters client-side here with.filter((r) => r.data.committee_uid === committeeId)`.

Why it's a problem: The query service supports tags filtering — getCommitteeSurveys in this same PR uses tags: \committee_uid:${committeeId}`to filter server-side. Fetching all project votes and filtering in memory is wasteful, won't scale for projects with many votes, and the 500page_size` cap means results can be silently truncated (there's even a warning log for this).

Fix: Use tags: \committee_uid:${committeeId}`in the query params instead ofparent: `project:${projectUid}`, matching the pattern used by getCommitteeSurveys`. This eliminates the client-side filter, the need for the 500 page_size workaround, and the truncation warning.

[asithade]

committee_uid is not a valid upstream parameter for meetings.

Problem: The params object includes committee_uid: committeeId, but the upstream meeting service does not accept committee_uid as a query parameter. The meeting service lists meetings by project_uid only — committee association is embedded within the meeting object's committees array. This param is either silently ignored (returning unfiltered results) or could cause an error.

Why it's a problem: If ignored, the endpoint returns all project meetings, not just committee-scoped ones — the frontend would show meetings from other committees. If the query service is used instead, it supports tags filtering like the survey endpoint does.

Fix: Verify which upstream service this actually hits. If it goes through the query service, use tags: \committee_uid:${committeeId}`for server-side filtering (matching thegetCommitteeSurveyspattern). If it goes through the meeting service directly, filter client-side by checkingmeeting.committees?.some(c => c.uid === committeeId)`, and document why server-side filtering isn't possible.

[manishdixitlfx]

Superseded by 4 focused PRs

This PR has been split into 4 smaller, independently reviewable PRs to unblock the review process:

PR	Scope	Lines	Status
#341	Backend BFF endpoints for meetings & surveys	~310	Ready for review
#343	Votes & surveys tab components	~430	Ready for review (depends on #341)
#342	Members tab & member form enhancements	~700	Ready for review (independent)
#344	Leadership dialog & committee view polish	~380	Draft (depends on #341 & #342)

Merge order

#341 (Backend BFF)          #342 (Members + Form)
     |                           |
     v                           |  (independent, review in parallel)
#343 (Votes + Surveys)          |
     |                           |
     +───────────┬───────────────+
                 v
           #344 (Leadership + Polish)

Review fixes applied across all PRs

• Removed votes BFF endpoint (votes-list uses VoteService directly)
• Record<string, string> type safety on query params
• Validate before logger.startOperation in surveys handler
• Removed duplicate logger.error in catch blocks
• Added loadError signal + error state UI to votes-list
• Query param whitelisting in meetings and surveys endpoints

Closing this PR in favor of the split PRs above.