ASSESSOR project guidance

Implementation plan

Read docs/IMPLEMENTATION_PLAN.md before architecture changes, broad refactors, persistence changes, importer/profile work, or server-readiness work.
State which plan phase the requested work belongs to and keep the change within the user's requested scope.
Preserve the currently working local application while moving toward the documented browser/server target architecture.
Do not mark a milestone or phase complete until its acceptance criteria have been verified.
After a material, verified implementation step, update the plan's status, decisions, risks, and change log in the same change. Do not rewrite historical decisions silently.
If the requested implementation conflicts with the plan, explain the conflict and update the plan only with the user's agreement or when the request explicitly supersedes it.

Keep format parsing, structural analysis, semantic mapping, normalization, comparison, persistence, and presentation separated.
Preserve original source values and provenance; normalized values must not destroy source data.
Known tool profiles must extend the generic import pipeline rather than bypass it.
React components must not contain source-specific parsing or direct database logic.
Treat Tauri as the current local shell and a possible optional future shell. Do not make new domain logic depend on Tauri when a platform-neutral boundary is possible.
The target deployment is an internal browser application with a backend and PostgreSQL. The browser must not access the database directly.

Render continuous prose and other content-bearing text at no less than 16px, including finding content, report text, Grid cell content, and Raw Data.
Compact interface text such as button captions, field labels, metadata, badges, and comparable control annotations may use a smaller type size.
When adding or changing styles, preserve this distinction instead of reducing content text to a compact UI-label token.

The Work panel is the binding spacing reference: content inside every rounded main panel starts 20px from each outer edge.
Use --panel-content-inset through its compatibility alias --panel-inset; do not introduce local substitute values for existing or future main panels.
Apply the inset exactly once on the view's root content container. Split panes and edge-to-edge structures belong inside that inset and must not add a second outer inset.
Keep the 20px outer inset at responsive breakpoints unless the user explicitly changes this standard.

Preserve local-only behavior until a server transition is explicitly implemented and documented.
Do not introduce external uploads, telemetry, CDN assets, network APIs, shell access, or broader Tauri capabilities without explicit user approval and a security-model update.
Treat imported HTML, XML, Excel, JSON, and CSV files as untrusted input. Never execute active content from imported files.
Use npm test and npm run build as the baseline verification commands for relevant changes.
Preserve unrelated user changes and keep implementation-plan updates factual and concise.

Treat all real tenant, customer, project, scan, finding, and imported-file data as sensitive.
Never inspect, extract, log, quote, summarize, screenshot, or otherwise expose real file names, finding titles, field values, raw report content, or rendered report text during testing or debugging.
Use synthetic fixtures for content-level, parser, importer, mapping, and UI tests.
Against a real running application, verify functionality only through content-free technical signals such as HTTP status, health state, anonymized counts, boolean DOM state, control availability, and element existence.
Do not read innerText, response bodies containing domain data, or screenshots of populated views merely to prove that a feature works.
If real content inspection is genuinely unavoidable, stop and obtain the user's explicit permission for the minimum required scope before accessing it.
Remove temporary browser profiles and test artifacts immediately after an approved real-application check.