Notes & Schedules

149 TypeScript files under src/, 22,437 lines, in four layers over one database. The path alias @/* maps to ./src/* in both tsconfig.json and jest.config.ts.

Twenty-seven route files: eighteen production, nine debug. Authentication is layered — src/middleware.ts protects everything by default and names eight public exceptions, and most protected routes then re-check the session for themselves.

Production routes

Debug routes

Specified but never built

PRD.md carries a route table written before implementation. Seven of its entries have no corresponding file. In most cases the capability exists — it simply arrived as a server action instead.

Public route matchers

const isPublicRoute = createRouteMatcher([
  '/sign-in(.*)',
  '/sign-up(.*)',
  '/api/webhooks(.*)',
  '/api/cron(.*)',       // Cron jobs use CRON_SECRET auth
  '/api/health(.*)',     // Health checks should be public
  '/api/categorize(.*)', // AI categorization endpoint
  '/api/debug(.*)',      // Debug endpoints (REMOVE IN PRODUCTION)
  '/privacy',            // Privacy policy (public for QuickBooks)
  '/terms',              // Terms of service (public for QuickBooks)
]);

Comments are the source's own. The privacy and terms pages are public because Intuit requires a published policy before granting production OAuth access — which is also why those two pages exist in src/app/ at all.

Common response conventions

1,088 test blocks across 50 files and 16,649 lines — 0.74 lines of test for every line of source. The distribution is heavily weighted toward the agent boundary and the markdown renderer, the two places where behaviour is defined by a long list of discrete cases rather than by a single control flow.

Where the assurance is not

The pattern is consistent: almost everything built in Phases 1 to 9 is covered, and almost nothing added in Phase 10 is. That matches the four unticked assurance items in TASKS.md.

CLAUDE.md requires that completed tasks record their test count in TASKS.md. That makes the file auditable: the recorded figures can be compared against the blocks actually present.

Eight of eleven agree exactly. The three that differ are the entries whose files were later extended without the earlier line being revised — the same drift that left the tool count assertion at nineteen. Every figure recorded against a component that was finished and not revisited still agrees, which is why the figures on Sheet 1 are drawn from mechanical counts rather than from the summary table.

Fourteen variables are referenced. DEPLOY.md lists seven; the other seven are discoverable only by reading code. Names only appear below — no values.

Local development reads .env.local, loaded by dotenv from jest.env.ts, drizzle.config.ts, check-qb.js and the three files in scripts/. .gitignore excludes .env* wholesale.

Thirteen scripts. Five wrap drizzle-kit; the rest are the standard Next.js and Jest entry points.

$ npm run

Scripts available in gogenticcfo@0.1.0 via `npm run-script`:
  dev
    next dev
  build
    next build
  start
    next start
  lint
    eslint
  test
    jest
  test:watch
    jest --watch
  test:coverage
    jest --coverage
  typecheck
    tsc --noEmit
  db:generate
    drizzle-kit generate
  db:migrate
    drizzle-kit migrate
  db:push
    drizzle-kit push
  db:studio
    drizzle-kit studio
  db:seed
    npx tsx src/server/db/seed.ts

Script bodies are quoted verbatim from package.json. Because test is bare jest, npm test -- <path> forwards the path straight through, which is the form used in the terminal renderings on Sheets 3 and 5.

The Definition of Done

The four suites that talk to a real database are __tests__/server/db/seed.test.ts, __tests__/server/patterns/index.test.ts, __tests__/server/sync/transactions.test.ts and __tests__/lib/queries/chat.test.ts. Each carries a @jest-environment node docblock, opens its own Neon connection, and tears down its fixtures — the pattern tests delete every row whose pattern begins TEST_ in an afterAll.

Nine items in TASKS.md are unticked. They cluster in two places: the tail of the polish phase, and the tests for the most recent feature.

All four assurance items are corroborated by the file listing rather than taken on trust. A fifth, unlisted, belongs with them: the debug routes carry DELETE THIS ENDPOINT BEFORE PRODUCTION! comments and a matching note in middleware.ts, but no task tracks their removal.

Points where the code contradicts the specification, the tests contradict the code, or the code contradicts itself. They are listed because a technical record that reports only agreement is not much of a record. Several are simply the ordinary residue of a system built quickly in phases; a few are worth acting on.

Accessibility, as evidenced

TASKS.md 6.2 marks an accessibility audit complete. The component tests corroborate it — not as a claim, but as assertions that would fail if the attributes were removed.

Two related items remain open — performance optimisation and mobile responsiveness QA — so the audit covered semantics rather than layout.

This record was prepared by reading the repository: 149 source files, three migrations, the committed configuration, the specification set, and a fifty-file test suite. Where a claim on these sheets could be checked against more than one of those, it was.

The basis markers exist because those sources do not always agree. A behaviour read from src/ is what the application does. A behaviour pinned by a test is what it was expected to do when the test was written — usually the same thing, and occasionally, as the register above records, not. A behaviour stated only in PRD.md is an intention, and at least seven of those intentions were met a different way or not at all. Where the sources disagree, this record follows the code.

Deliberately excluded

This is a private business repository, and parts of it hold live financial and personal data. The following were read only far enough to establish their shape, and are not reproduced anywhere in this record — not in summary, not in aggregate, and not as illustrative figures.

Where a name does appear on these sheets it is one of three things: a package name, a well-known brand written into a test as a string-handling fixture, or a payroll line-item label such as Debit net pay that the parser mistakes for a person. No balance, revenue figure, payroll amount, hourly rate, headcount, client name, employee name, bank account identifier or QuickBooks realm identifier from the source system appears anywhere in this record.