MOPC-Portal/.planning/STATE.md

gsd_state_version, milestone, milestone_name, status, last_updated, progress

gsd_state_version	milestone	milestone_name	status	last_updated	progress
1.0	v1.0	milestone	in_progress	2026-02-27T08:56:00Z	total_phases completed_phases total_plans completed_plans 4 2 10 7

Project State

Project Reference

See: .planning/PROJECT.md (updated 2026-02-26)

Core value: Admins can describe ranking criteria in natural language, the system interprets and ranks projects accordingly, and they can advance the top projects to the next round with one click — all with full override control. Current focus: Phase 2 — Ranking Dashboard UI

Current Position

Phase: 2 of 4 (Ranking Dashboard UI) — COMPLETE Plan: 3 of 3 in current phase (Phase 2 all plans complete) Status: In progress (Phase 3 next) Last activity: 2026-02-27 — Plan 02-03 complete: Advance Top N dialog + batch-reject wired to tRPC mutations

Progress: [███████░░░] ~70%

Performance Metrics

Velocity:

• Total plans completed: 5
• Average duration: ~5 min
• Total execution time: ~23 min

By Phase:

Phase	Plans	Total	Avg/Plan
01-ai-ranking-backend	4	~18 min	~5 min
02-ranking-dashboard-ui	3	~18 min	~6 min

Recent Trend:

• Last 5 plans: 01-04 (~8 min), 02-01 (~5 min), 02-02 (~8 min), 02-03 (~5 min)
• Trend: Fast (service-layer + UI implementation tasks)

Updated after each plan completion | Phase 02-ranking-dashboard-ui P01 | 5 | 2 tasks | 3 files | | Phase 02-ranking-dashboard-ui P02 | 8 | 1 task | 1 file | | Phase 02-ranking-dashboard-ui P03 | 5 | 1 task | 1 file |

Accumulated Context

Decisions

Decisions are logged in PROJECT.md Key Decisions table. Recent decisions affecting current work:

• [Init]: RankingSnapshot model (new table) preferred over Round.metadataJson for audit history — confirm with client before writing migration
• [Init]: Per-category processing (STARTUP / BUSINESS_CONCEPT) — two parallel AI calls, not one combined call
• [Init]: Phase 4 is independent and can be parallelized with Phases 2-3
• [01-01]: Used separate relation names per FK pair (RoundRankingSnapshots / TriggeredRankingSnapshots) — Prisma requires unique relation names per FK, not per target model
• [01-01]: All EvaluationConfig ranking fields are optional/defaulted for backward compatibility with existing rounds
• [01-01]: Created migration SQL manually (20260227000000_add_ranking_snapshot) — local DB credentials unavailable; migration applies on next deploy
• [01-02]: fetchAndRankCategory exported (not private) so tRPC router can execute pre-parsed rules without re-parsing
• [01-02]: Projects with zero SUBMITTED evaluations excluded from ranking entirely (not ranked last)
• [01-02]: PrismaClient imported as real type (not import type) so transaction clients are compatible
• [01-03]: Typed arrays cast to Prisma.InputJsonValue via unknown (direct cast rejected by strict TS — no index signature)
• [01-03]: getSnapshot uses findUnique + manual TRPCError NOT_FOUND (findUniqueOrThrow gives INTERNAL_SERVER_ERROR)
• [Phase 01-04]: triggerAutoRankIfComplete defined as module-level non-exported function in evaluation.ts — avoids circular imports, colocated with the mutation it serves
• [Phase 01-04]: EvaluationConfig null fallback typed as {} as EvaluationConfig — required for TypeScript strict mode to recognize rankingCriteria and autoRankOnComplete fields
• [Phase 01-04]: retroactiveScan uses RETROACTIVE triggerType to distinguish from MANUAL/AUTO/QUICK — prevents duplicate re-runs on subsequent scans
• [02-01]: ReorderEvent type defined locally in ranking.ts (not exported) — only consumed by saveReorder procedure
• [02-01]: saveReorder is append-only: full ordered list stored per event, latest entry per category = current admin order, gives full audit trail
• [02-02]: Double cast (as unknown as RankedProjectEntry[]) required for Prisma JsonValue — direct cast rejected by TypeScript strict mode
• [02-02]: getFullDetail returns { project, assignments, stats } shape — title accessed via .project.title not root level
• [02-02]: saveReorder has no onSuccess invalidation — avoids re-fetch that would reset localOrder and cause snap-back
• [02-03]: Advance button disabled via saveReorderMutation.isPending (reactive) not pendingReorderCount.current (ref, non-reactive)
• [02-03]: topNStartup + topNConceptual === 0 disables confirm button — prevents no-op advance calls
• [02-03]: batchRejectMutation fires conditionally (only if includeReject and rejectIds.length > 0)

Pending Todos

None yet.

Blockers/Concerns

• [Phase 1]: French/English variable naming for EmailTemplate bilingual fields needs client confirmation before Phase 3 schema migration
• [Phase 1]: Poste.io bulk-send rate limits need verification before Phase 3 load testing
• [Phase 3]: Tiptap Mention extension API in v3.x should be validated against Tiptap v3 docs before implementation

Session Continuity

Last session: 2026-02-27 Stopped at: Completed 02-03-PLAN.md (Advance Top N dialog + batch-reject — Phase 2 complete) Resume file: None