MichilisandClaude Opus 5
6620650e9e
Formulario 120 and 515 assembly, the review screen, approval, the PDF, and the guided checklist that walks the user through presenting it in Marangatu. Approval is a promise about what the user actually saw: the numbers are recomputed on the way in, and if the documents moved since the declaration was generated the answer is a 409 with the fresh figures stored as a draft, not a silent approval of numbers nobody read. An approved declaration is never regenerated or invalidated. Editing, confirming, rejecting or reclassifying a document flips any ready declaration covering its period back to draft, which is what the dashboard reads to stop offering it for review. The PDF is rendered once and cached against the declaration, so two downloads are byte for byte the same document; every write that changes the numbers clears the cache. Approval pre-renders it, and the route renders on demand, so a failed job costs a wait rather than a missing file. It stays Spanish in both locales, like the form it mirrors, and carries a BORRADOR watermark until it is approved. The seeded declarations are computed through the same code path the product uses, so their figures agree with the documents behind them. Three defects the screenshots caught: the floating scan button swallowed the tap meant for Aprobar on a phone, the summary breakdown reused labels meant for other screens, and five tab labels collided at 390px. Tests that can avoid depending on a fresh seed now do; the ones that cannot say so in the assertion rather than timing out. db:reset warns that the API has to be stopped first, having learned that the hard way. 293 vitest tests, 59 Playwright tests, rules coverage still 100%, typecheck and lint clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
98 lines
3.3 KiB
TypeScript
98 lines
3.3 KiB
TypeScript
import Database from 'better-sqlite3';
|
|
import { fileURLToPath } from 'node:url';
|
|
|
|
/**
|
|
* Read only access to the stack's database, used to assert the rows a flow was supposed
|
|
* to write and to read the emailed verification code (which development prints to the
|
|
* server console rather than sending). Only valid against a local SQLite stack.
|
|
*/
|
|
const DB_PATH =
|
|
process.env['E2E_DB_PATH'] ?? fileURLToPath(new URL('../apps/api/data/app.db', import.meta.url));
|
|
|
|
function open(): Database.Database {
|
|
return new Database(DB_PATH, { readonly: true, fileMustExist: true });
|
|
}
|
|
|
|
function query<T>(run: (db: Database.Database) => T): T {
|
|
const db = open();
|
|
try {
|
|
return run(db);
|
|
} finally {
|
|
db.close();
|
|
}
|
|
}
|
|
|
|
/** better-auth stores the code as `<otp>:<attempts>` against the recipient's address. */
|
|
export function readVerificationOtp(email: string): string {
|
|
return query((db) => {
|
|
const row = db
|
|
.prepare('select value from verification where identifier = ? order by createdAt desc limit 1')
|
|
.get(`email-verification-otp-${email}`) as { value: string } | undefined;
|
|
if (!row) throw new Error(`no verification code was issued for ${email}`);
|
|
return (row.value.split(':')[0] ?? '').trim();
|
|
});
|
|
}
|
|
|
|
export function readProfile(email: string): Record<string, unknown> | undefined {
|
|
return query(
|
|
(db) =>
|
|
db
|
|
.prepare(
|
|
'select p.* from profiles p join user u on u.id = p.user_id where u.email = ?',
|
|
)
|
|
.get(email) as Record<string, unknown> | undefined,
|
|
);
|
|
}
|
|
|
|
export function readAuditActions(email: string): string[] {
|
|
return query((db) => {
|
|
const rows = db
|
|
.prepare(
|
|
'select a.action from audit_log a join user u on u.id = a.subject_user_id where u.email = ? order by a.created_at',
|
|
)
|
|
.all(email) as { action: string }[];
|
|
return rows.map((row) => row.action);
|
|
});
|
|
}
|
|
|
|
export function readConsents(email: string): { kind: string; revoked: boolean }[] {
|
|
return query((db) => {
|
|
const rows = db
|
|
.prepare(
|
|
'select c.kind, c.revoked_at from consents c join user u on u.id = c.user_id where u.email = ?',
|
|
)
|
|
.all(email) as { kind: string; revoked_at: string | null }[];
|
|
return rows.map((row) => ({ kind: row.kind, revoked: row.revoked_at !== null }));
|
|
});
|
|
}
|
|
|
|
/**
|
|
* The newest month that has confirmed documents but no declaration yet.
|
|
*
|
|
* Approving is a one way door, so a test that always used the same period would only pass
|
|
* on a freshly seeded database. Picking an unused month lets the declaration flow run
|
|
* repeatably against a stack that has already been exercised.
|
|
*/
|
|
export function findMonthWithoutDeclaration(email: string): string | null {
|
|
return query((db) => {
|
|
const row = db
|
|
.prepare(
|
|
`select substr(d.issue_date, 1, 7) as period
|
|
from documents d
|
|
join user u on u.id = d.user_id
|
|
where u.email = ? and d.status = 'confirmed'
|
|
and not exists (
|
|
select 1 from declarations dec
|
|
where dec.user_id = d.user_id
|
|
and dec.form_code = '120'
|
|
and dec.period = substr(d.issue_date, 1, 7)
|
|
)
|
|
group by period
|
|
order by period desc
|
|
limit 1`,
|
|
)
|
|
.get(email) as { period: string } | undefined;
|
|
return row?.period ?? null;
|
|
});
|
|
}
|