51 lines
4.2 KiB
Markdown
51 lines
4.2 KiB
Markdown
# 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.
|
|
|
|
## Architectural boundaries
|
|
|
|
- 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.
|
|
|
|
## UI typography
|
|
|
|
- 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.
|
|
|
|
## UI panel spacing
|
|
|
|
- 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.
|
|
|
|
## Security and verification
|
|
|
|
- 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.
|
|
|
|
## Privacy-safe testing
|
|
|
|
- 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.
|