Repository for the assessment model application
Find a file
Daniel Roth 9f091d7b79 feat(ara-projects): programme dashboard + shared work-order derivations
Implements #418: `/projects/[projectId]` as a Server Component over SQL
aggregates, plus the shared derivation helpers that #419 and #422 are
instructed to reuse rather than reimplement.

## The shared interface — `src/lib/projects/derivations.ts`

Pure, no db client, no table shapes; unit-tested against in-memory
fixtures. This is the single source of truth for *complete*, *overdue*
and *evidence completeness*. Code against it sight-unseen:

    buildStageLadders(stages: StageLadderEntry[]): StageLadders

Resolve the ladder once, then ask it questions. `StageLadderEntry` is
`{ id, projectWorkstreamId, order }` — one `project_workstream_stage`
row. Pass EVERY stage of every workstream you will ask about; a partial
ladder derives the wrong terminal stage.

Row-level, over `WorkOrderDerivationInput`
(`{ projectWorkstreamStageId, forecastEnd: string | Date | null }`):

    progressOfWorkOrder(ladders, wo): "not_started" | "in_progress" | "complete" | null
    isComplete(ladders, wo): boolean
    isOverdue(ladders, wo, asOf: Date): boolean

Set-level, for pushing into SQL instead of streaming rows into JS:

    ladders.stageIdsByProgress(progress): bigint[]
    ladders.isTerminalStage(stageId): boolean
    ladders.orderOfStage(stageId) / ladders.workstreamOfStage(stageId)

Evidence (advisory counts only — never a gate, per CONTEXT.md):

    requiredEvidenceRequirementIds(ladders, requirements, stageId): bigint[]
    evidenceCompleteness(required, satisfied): EvidenceCompleteness
    sumEvidenceCompleteness(parts): EvidenceCompleteness
    isMissingRequiredEvidence(completeness): boolean

`EvidenceCompleteness` is `{ required, satisfied, missing, ratio }` where
`ratio` is `null` — not `0` — when nothing is required, so "unconfigured"
and "0% met" stay distinguishable. `sumEvidenceCompleteness` sums counts
before dividing rather than averaging percentages.

Also exported: `toCalendarDay(value)`, which normalises a `date` column
value to `YYYY-MM-DD` UTC. Bind it as a SQL parameter rather than using
`CURRENT_DATE`, so a page and its queries measure against the same day
across midnight.

### Rules, as decided in the issue

- complete  = stage is the ladder's terminal stage (highest `order`)
- overdue   = `forecast_end` strictly before today AND not complete
- evidence  = advisory counts of submissions against required requirements

### Edge cases pinned down (documented because two tickets depend on them)

- Single-stage ladder is terminal, not first: it reads `complete`.
- Every stage tied at the maximum `order` is terminal (and at the minimum,
  first) — `order` is not unique in the schema, so this stays deterministic.
- Unknown/unloaded stage id derives `null` progress: not complete, and
  still eligible to be overdue.
- Dates compare as calendar days in UTC. Due *today* is not overdue.
- A stage-scoped requirement applies once the work order has REACHED that
  stage (`requirement order <= work order order`); unscoped applies always.
  Only `required = true` requirements count.

## Aggregating in SQL without duplicating the rules

`src/app/repositories/projects/dashboardRepository.ts` counts in the
database — one grouped query over (workstream, contractor, stage) returns
a few hundred rows regardless of the work-order count. The rules are not
restated in SQL:

- Terminal-ness is never asked of SQL. The aggregate groups by stage id;
  `buildStageLadders` classifies those few dozen ids in JS.
- Overdue is split at its `AND`: SQL counts rows past their forecast day
  (`pastForecast`), and `overdueOf` drops terminal groups.
- Evidence applicability is decided by `requiredEvidenceRequirementIds`
  and handed to SQL as a `(stage_id, requirement_id)` VALUES list — it
  crosses into SQL as data, never as a re-implemented predicate.

`src/lib/projects/dashboardSummary.ts` folds those grouped rows into the
four bands, so the KPI totals and the tables beneath them are derived from
the same aggregate and cannot disagree.

## Notes

- "Unassigned contractor" is structurally unreachable in v1
  (`work_order.project_workstream_contractor_id` is NOT NULL), so the
  count reads 0. It is computed via a LEFT JOIN rather than hard-coded so
  it becomes truthful on its own if that column is ever relaxed.
- Authorization is left on the existing `../authz` route seam, which the
  per-project layout also applies. Replacing it with `@/lib/projects/authz`
  is #409's work; this change adds no permission logic of its own.
- "Awaiting auth", "No access" and notifications are cut from the
  wireframe, as the issue specifies — no schema support.

## Seeding: written, NOT run

`src/app/db/seed/seed-projects-dashboard.ts` seeds ~1,500 work orders so a
human can check the render at programme scale. **It was deliberately never
executed.** The database reachable from this environment is the shared
PRODUCTION database, so seeding from here would have written fabricated
delivery records into live data. Run it yourself against a non-production
database:

    ALLOW_PROJECTS_DASHBOARD_SEED=i-am-not-production \
      npx tsx src/app/db/seed/seed-projects-dashboard.ts <projectId>

It refuses to run without that variable, refuses under NODE_ENV=production,
and prints DB_HOST with a 5s pause before writing. Everything it inserts is
prefixed `SEED-418-` so it can be removed again.

Consequently the "renders acceptably with ~1,500 seeded orders" criterion
is UNVERIFIED — it needs that script run on a scratch database and the page
opened. The query shape is designed for it (grouped counts, bounded result
set), but designed-for is not measured.

## Tests

110 tests over the derivation logic, the fold and the query construction —
in-memory fixtures throughout. The repository test stubs `@/app/db/db` via
`vi.mock` so no `pg.Pool` is ever constructed and no connection can open.
Full suite: 618 passed. Typecheck and lint clean. Cypress not run.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-21 16:54:43 +00:00
.claude save 2026-06-29 10:54:48 +00:00
.devcontainer pull latest agentic-toolkit version 2026-07-21 10:05:23 +00:00
.github/workflows updating CI 2026-05-05 19:36:33 +00:00
.impeccable/critique feat(portfolio): address impeccable critique — no-plans state, contrast, focus 2026-07-13 21:50:27 +00:00
.vscode added db filtereing 2026-01-05 17:30:58 +00:00
backlog update instruction doc and context 2026-06-03 10:33:52 +00:00
cypress fix(ara-projects): require user onboarding before /projects 2026-07-21 16:08:47 +00:00
docs docs(ara-projects): ADR-0018 + CONTEXT.md Ara Projects domain language 2026-07-21 08:30:32 +00:00
drizzle/meta Got drizzle orm working 2023-07-10 17:48:37 +01:00
public added robots and security txt files 2026-03-10 18:56:53 +00:00
src feat(ara-projects): programme dashboard + shared work-order derivations 2026-07-21 16:54:43 +00:00
.db-env added files for reports 2025-10-30 17:15:30 +00:00
.eslintrc.json Initial commit from Create Next App 2023-05-25 06:07:00 +01:00
.gitignore fix(live): flag major condition issues by the issue, not a retired stage / S3 URL 2026-07-20 16:42:55 +01:00
CLAUDE.md updated claude.md 2026-05-06 16:11:00 +00:00
components.json Added layout of toolbar n portfolio page 2023-07-12 15:41:58 +01:00
CONTEXT.md docs(ara-projects): ADR-0018 + CONTEXT.md Ara Projects domain language 2026-07-21 08:30:32 +00:00
cypress.config.ts Creating automated testing - blocked until we have a test account 2023-07-11 12:14:48 +01:00
devcontainer.sh pr for claude skills 2026-05-05 19:53:21 +00:00
drizzle.config.ts Fix drizzle-kit schema glob and generate Projects migration 2026-07-17 15:36:08 +00:00
generate_migration.sh added migration scripts and ability to add a deal in hubspot@ 2025-10-22 15:44:00 +00:00
migrate_to_db.sh new migration files 2026-06-03 12:55:49 +00:00
next.config.js revamping the plan page 2026-04-10 21:54:26 +00:00
package-lock.json Surface coordinator damp & mould commentary in the risk drill-down 2026-05-28 14:58:23 +00:00
package.json perf(backfill): faster, resumable recommendation denormalization + ops tooling 2026-07-02 10:00:46 +00:00
postcss.config.js Initial commit from Create Next App 2023-05-25 06:07:00 +01:00
PRODUCT.md docs(design): home-page redesign context — Stitch refs, PRODUCT.md, impeccable trial 2026-07-07 15:12:07 +00:00
README.md deploy? 2026-05-28 13:52:01 +00:00
run_build.sh addded changes to let build work 2025-08-21 11:30:51 +00:00
run_local.sh automated script that ran for next 15 2025-07-22 10:50:50 +00:00
skills-lock.json Updated survey request UI for Devon County Council 2026-05-06 20:37:30 +00:00
tailwind.config.js re-vamping ara ui 2026-04-08 10:29:14 +00:00
tsconfig.json minor visual tweaks 2026-04-10 22:49:00 +00:00
vitest.config.ts fixing multi company bug 2026-05-07 20:08:04 +00:00

This is a Next.js project bootstrapped with create-next-app.

Getting Started

When first getting set up you'll firstly want to install the existing dependencies. To do this, simply run

npm install
# or
yarn install

First, run the development server:

npm run dev
# or
yarn dev
# or
pnpm dev

Open http://localhost:3000 with your browser to see the result.

You can start editing the page by modifying app/page.tsx. The page auto-updates as you edit the file.

This project uses next/font to automatically optimize and load Inter, a custom Google Font.

Learn More

To learn more about Next.js, take a look at the following resources:

You can check out the Next.js GitHub repository - your feedback and contributions are welcome!

Deploy on Vercel

The easiest way to deploy your Next.js app is to use the Vercel Platform from the creators of Next.js.

Check out our Next.js deployment documentation for more details.

We currently have a development version, found at https://assessment-model-dev.vercel.app, and a production version at https://assessment-model.vercel.app, however the production version is missing a significant number of environmental variables, which will need to be added.

Drizzle ORM

We're using Drizzle ORM to interface with our AWS Postgres database. Documentation on getting set up can be found here

Schemas

In order to get started with Drizzle, a schema needs to be created. Schemas can be added src/app/db/schema as typescript files. See the documentation on how to set up schemas but effectively, Drizzle allows you to define schemas as typescript code, which allows for simple, type safe schema definitions.

Creating Migrations

To create a migration, a command has been set up in package.json. Simply run

npm run migration:generate

Or with yarn/pnmp accordingly.

Note, there seems to be a bug with Drizzle which is documented here.

The workaround is to open up tsconfig.json and comment out "target": "es5", and replace it with "target": "ESNext". This should hopefully only be a temporary workaround required.

Pushing migrations

To push migrations, another command has been set up in package.json, since drizzle-kit currently does not support pushing for Postgres out of the box.

Run

npm run migration:push

Which will commit changes to the database. The database changes will be pushed to the public schema, whereas a meta record will be pushed to the __drizzle_migrations schema.

Inserting users into the database

In order to insert a user into the database, simply run

npm run create_users -- {email} {firstName}

Since we're using just the built in process arguments to read command line arguments, the ordering of arguments needs to be email address and then name

Cypress Testing Documentation

This document provides an overview of how to perform end-to-end testing using Cypress for the login functionality of the application. The testing code is based on the provided code snippets.

Prerequisites

Node.js installed on your machine Cypress installed as a dev dependency in your project

Test Execution

To execute the login tests, follow these steps:

  1. Run
npm run test:e2e:open

Which will open Crypress test runner

  1. Select the tests that you want to run. At the time of writing, only login tests have been completed

Key files

The key files that are at play for testing are documented here. Because of some issues testing next-auth and setting cookies, a custom command to set the JWT, and avoid the functionality defined in the signIn function as defined in src/app/api/auth/[...nextauth]/route.ts

cypress/plugins/index.js is a standard file, required by cypress to journey through the Google Oauth flow

cypress/figtures/session.json is a user fixture that is used to log in a user in the login tests

cypress/support/commands.ts creates a custom login user command which sets a JWT and allows us to actually authenticate. cy.intercept only mocks the client side behaviour of the apis and therefore does not set any cookies, do this function does this manually.

Generating pre-signed urls

In our terraform stack, we have a module called s3_presignable_bucket which contains the definition for our bucket which we will use to store retrofit plan input csv's in.

We will generate a pre-signed url and then make a post request to that endpoint to store that data to s3. Part of that process is the creation of an AWS IAM role which contains the permission set to access the bucket, rerofit-plan-inputs-<stage>. The name of this IAM role is s3_presign_role_<stage> and for our NextJS application, as it's hosted outside of AWS (for the moment), we need to generate a set of access credentials to give the application access to this bucket. The access key and secret key are automatically generated and stored in AWS secrets manager under dev/presign_frontend/access_key and dev/presign_frontend/secret_key and need to be set in the environment for the pre-sign api to store csv data to aws.