jramos/cve-dashboard
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore: remove .kiro specs, hooks, and steering from release — development tooling only

Browse Source
This commit is contained in:
Jordan Ramos
2026-05-01 21:28:59 +00:00
parent 7f7d3a2977
commit af951fdc12
91 changed files with 1 additions and 12313 deletions
Download Patch File Download Diff File Expand all files Collapse all files

190
.kiro/steering/doc-standards.md
View File

@@ -1,190 +0,0 @@
# Documentation Standards — CVE Dashboard
These standards are reverse-engineered from the existing README.md and should be treated as the canonical style guide for all documentation in this repository. When updating docs, match these conventions exactly — consistency matters more than any individual stylistic preference.
---
## Language and Style
- Write in **present tense, active voice**. "The sync fetches findings" — not "Findings will be fetched by the sync."
- Do not use marketing language. No "powerful", "seamless", "robust", "cutting-edge", "unleash". Describe what the thing does, not how great it is.
- No emoji anywhere in documentation. None.
- Prefer precise technical vocabulary over casual phrasing. "Session tokens are stored in `httpOnly` cookies" — not "we keep the login thing in a secure cookie."
- **Spelling:** match whatever spelling variant already appears in the surrounding prose. Do not rewrite existing words to switch between US and British English — consistency within a section matters more than which variant is used.
---
## Punctuation and Formatting
- **Em-dashes (—)** for mid-sentence clarifications or appositives, surrounded by spaces: `sync requires Admin or Standard_User group — the sync then fetches findings`.
- **En-dashes (–)** for numeric ranges: `8.5–9.9 VRR`, `20 attempts per 15-minute window`.
- Use **inline backticks** for: file paths, environment variables, CLI flags, function names, field names, HTTP status codes, and any literal value the reader should type or recognise verbatim.
- Use **bold** (`**text**`) for UI element names (button labels, tab names, form fields) and for label-style emphasis at the start of a sub-point.
- Avoid italics except for rare genuine emphasis. Do not use italics decoratively.
---
## Heading Hierarchy
Use a strict three-tier hierarchy per document:
```
# Document Title (one per file, matches repo/feature name)
## Top-Level Section (Overview, Features, Architecture, etc.)
### Subsection (a named feature, page, or concept)
**Sub-subsection label** (bold paragraph labels — NOT an #### heading)
```
- Do **not** use `####` or deeper headings. If you need a fourth level, it should be a bold inline label followed by content, matching the existing README pattern.
- Separate top-level `##` sections with a horizontal rule (`---`) on its own line, with blank lines above and below.
- Do not place horizontal rules between `###` subsections unless visually necessary.
---
## Table of Contents
- Any document over ~200 lines should open with a Table of Contents using markdown anchor links.
- Nest TOC entries to match heading depth (`##` entries flush-left, `###` entries indented two spaces).
- Anchor slugs: lowercase, spaces become hyphens, em-dashes become `--` (two hyphens). Example: `## Home — CVE Management` becomes `#home--cve-management`.
---
## Tables
Use tables for any reference material with two or more parallel attributes. This includes:
- Permission matrices (group → capabilities)
- Tech stack listings (layer → technology)
- Column descriptions (column → meaning)
- Environment variable references (name → purpose → default)
- Route references (method + path → description → auth requirement)
Table format:
```markdown
| Column | Description |
|---|---|
| `field_name` | What it does |
```
- Always use `---` separators (not `:---:` centred alignment) unless centring is specifically warranted.
- Keep cell content on a single line. If a value is long, prefer prose above or below the table.
- Use inline backticks for literal values inside cells.
---
## Code Blocks
- **Always include a language tag** on fenced code blocks: ` ```bash `, ` ```javascript `, ` ```json `, ` ```python `, ` ```sql `. Bare ` ``` ` is not acceptable.
- Shell commands use `bash` — even for single-line commands.
- Place code blocks on their own line, with blank lines before and after.
- Inside code blocks, do not use markdown formatting (no bold, no italics). Treat them as literal terminal/file content.
- Prefer showing the actual command over describing what to do. "Run `node setup.js` from `backend/`" with a code block — not "initialize the database."
---
## Callouts and Warnings
- Use a blockquote (`>`) for callouts, notes, and warnings. Do not use GitHub-flavoured admonition syntax (`> [!NOTE]`), Docusaurus admonitions, or custom HTML.
- Keep callouts to one or two sentences. If longer, promote to prose.
- Example: `> IVANTI_API_KEY must be set in backend/.env for sync to work.`
Bold prefixes for emphasis are acceptable inside a blockquote: `> **Warning:** This deletes all audit records older than 90 days.`
---
## Feature Documentation Pattern
When documenting a feature or page, follow this structure:
1. **One-sentence summary** of what the feature is and who uses it.
2. **Capability bullets** — what a user can do, grouped by role if access-controlled.
3. **Workflow or interaction details** — how the feature is used in practice (inline editing behaviour, filter semantics, persistence rules).
4. **Integration notes** — what external systems it touches, what credentials it needs, what it caches.
5. **Edge cases and restrictions** — delete rules, rate limits, role requirements.
Bold paragraph labels (`**Inline editing:**`, `**CVE Tooltips:**`, `**Filtering:**`) are the preferred pattern for calling out sub-behaviours within a feature section.
---
## Troubleshooting Entries
Every troubleshooting entry uses the **Symptom → Cause → Fix** triad:
```markdown
### Short description of the problem
**Symptom:** What the user sees or experiences. Be specific about error messages, console output, and observed behaviour.
**Cause:** The underlying reason, explained in one or two sentences. Include the technical mechanism (cookie flag, rate limiter, missing migration) — not just "it's broken."
**Fix:** Either:
1. Concrete action with a command or config change, **or**
2. Alternative action.
```
- Short entries (fix is one command) may collapse Cause into Fix, but Symptom must always appear explicitly.
- Use **Fix:** as the label, not "Solution" or "Resolution."
---
## CHANGELOG
This project does not currently maintain a `CHANGELOG.md`. The doc-updater agent should **not** create one unless explicitly instructed.
When a change ships, rely instead on:
- **Git commit messages** as the primary change history. Write them as complete sentences describing user-observable behaviour, not implementation detail. "Add inline editing to CVE reporting table" — not "fix table.jsx."
- **README updates** as the user-facing record of what the app does now. The README is the source of truth for current behaviour; git log is the source of truth for when and why it changed.
If a `CHANGELOG.md` is introduced later, this section should be rewritten to declare the chosen format. Until then, the agent should leave changelog concerns out of scope.
---
## Migration Documentation
When a feature requires a new database migration:
1. Add the migration filename to the README's **Migrations** section in the order it must be run.
2. If the migration is required for an existing deployment (not just fresh installs), add a Troubleshooting entry using the Symptom → Cause → Fix pattern for the error users will see if they skip it.
3. Note any data-transforming migrations explicitly — users need to know whether the migration is additive (safe to re-run) or transformative (destructive if re-run).
---
## API Reference Documentation
- Document routes as: `METHOD /path/with/:params`
- Group routes by resource or page (CVE routes, Ivanti routes, Audit routes).
- For each route, specify: purpose, required group, request body or query params, response shape summary. Keep it to 2–4 lines per route.
- Do not duplicate route implementation details. Link to the source file if deeper reference is needed.
- When a route enforces group-based authorisation, state the required group explicitly — do not imply it from context.
---
## What to Update When a Feature Ships
A new feature or meaningful change to existing behaviour should touch:
1. **README.md — Features section:** add or update the relevant `###` subsection, matching the Feature Documentation Pattern above.
2. **README.md — Table of Contents:** if a new feature added a new heading, update the TOC to match.
3. **README.md — Configuration:** if new env vars were introduced, add them to the Configuration table.
4. **README.md — API Reference:** if new routes were added, document them under the appropriate resource group.
5. **README.md — Database Schema:** if tables or columns changed, update the schema section.
6. **README.md — Migrations:** if a new migration was added, append it to the ordered list.
7. **docs/**: if the feature has its own standalone guide (setup guide, integration guide), create or update the relevant file in `docs/`.
If a change does not alter user-observable behaviour, configuration, data model, or API surface, it does not require doc changes. Internal refactors, test additions, and dependency bumps are exempt unless they change how the app is run or deployed.
---
## What NOT to Change
The doc-updater agent and human contributors alike should **leave alone**:
- Tone, voice, and spelling conventions of existing prose. Match, do not rewrite.
- Section ordering in the README — the current order is deliberate and reader-tested.
- Heading wording, unless the underlying feature has genuinely been renamed.
- Examples and command snippets that still work, even if they could be "more elegant."
- The overall shape of the Troubleshooting section — append new entries, do not reorganise existing ones.
Documentation churn is a cost. Only change what the code change requires.

27
.kiro/steering/product.md
View File

@@ -1,27 +0,0 @@
# Product Overview
The STEAM Security Dashboard is a self-hosted vulnerability management tool for the NTS-AEO-STEAM and NTS-AEO-ACCESS-ENG business units. It centralizes CVE tracking, Ivanti host finding triage, AEO compliance posture monitoring, FP/Archer exception workflows, and internal documentation in a single interface.
## Core Capabilities
- Searchable CVE list with per-vendor tracking and document storage
- NVD API integration for auto-populating CVE metadata
- Ivanti/RiskSense integration for syncing open host findings with FP workflow tracking
- Reporting page with charts, advanced filtering, inline editing, and CSV/XLSX export
- Ivanti Queue for batch-processing FP, Archer, and CARD workflows
- AEO Compliance page with weekly xlsx upload, diff preview, per-team metric health cards, and device-level violation tracking
- Archer risk acceptance ticket tracking (EXC numbers) linked to CVE/vendor pairs
- Knowledge base for internal documentation and policies
- Role-based access control (viewer, editor, admin) with full audit trail
## User Roles
| Role | Permissions |
|------|------------|
| viewer | Read-only access to all data |
| editor | All viewer permissions plus create/update operations |
| admin | All editor permissions plus delete, user management, and audit log access |
## Teams Tracked
Only **STEAM** and **ACCESS-ENG** teams are tracked in the compliance module.

83
.kiro/steering/structure.md
View File

@@ -1,83 +0,0 @@
# Project Structure & Conventions
## Directory Layout
```
cve-dashboard/
├── backend/ # Express API server
│ ├── server.js # Main entry point — app setup, middleware, CVE/document routes inline
│ ├── setup.js # One-time DB init + default admin creation
│ ├── cve_database.db # SQLite database (gitignored)
│ ├── uploads/ # File storage (gitignored)
│ ├── routes/ # Express route modules (factory pattern)
│ │ ├── auth.js
│ │ ├── users.js
│ │ ├── auditLog.js
│ │ ├── nvdLookup.js
│ │ ├── knowledgeBase.js
│ │ ├── archerTickets.js
│ │ ├── ivantiWorkflows.js
│ │ ├── ivantiFindings.js
│ │ ├── ivantiTodoQueue.js
│ │ └── compliance.js
│ ├── middleware/
│ │ └── auth.js # requireAuth(db), requireRole(...roles)
│ ├── helpers/
│ │ └── auditLog.js # logAudit() — fire-and-forget DB insert
│ ├── migrations/ # Sequential migration scripts (run manually with node)
│ └── scripts/ # Python utilities (compliance parsing, CSV import)
│
├── frontend/ # React 19 SPA (Create React App)
│ └── src/
│ ├── App.js # Main dashboard — CVE list, filters, modals, inline styles
│ ├── App.css # Global styles and CSS variables
│ ├── contexts/
│ │ └── AuthContext.js # Auth state provider (login, logout, role helpers)
│ └── components/
│ ├── LoginForm.js
│ ├── NavDrawer.js
│ ├── UserMenu.js
│ ├── CalendarWidget.js
│ ├── UserManagement.js
│ ├── AuditLog.js
│ ├── NvdSyncModal.js
│ ├── KnowledgeBaseModal.js
│ ├── KnowledgeBaseViewer.js
│ └── pages/ # Full-page views
│ ├── ReportingPage.js
│ ├── CompliancePage.js
│ ├── ComplianceUploadModal.js
│ ├── ComplianceDetailPanel.js
│ ├── ComplianceChartsPanel.js
│ ├── IvantiCountsChart.js
│ ├── KnowledgeBasePage.js
│ └── ExportsPage.js
│
├── docs/ # Internal documentation (markdown)
├── start-servers.sh # Start both servers in background
├── stop-servers.sh # Stop both servers
└── DESIGN_SYSTEM.md # UI design system reference (colors, typography, components)
```
## Backend Conventions
- Route modules export a factory function: `function createXxxRouter(db, ...middleware)` that returns an Express Router.
- The `db` (sqlite3 Database instance) is passed via dependency injection from `server.js`.
- Auth middleware: `requireAuth(db)` validates session cookie, attaches `req.user`. `requireRole('editor', 'admin')` checks role.
- All state-changing actions call `logAudit(db, { userId, username, action, entityType, entityId, details, ipAddress })`.
- Input validation is done inline in route handlers with early-return error responses.
- SQLite queries use the callback-based `db.run()`, `db.get()`, `db.all()` API.
- API routes are prefixed with `/api`. All endpoints except login/logout require a valid session cookie.
- CVE and document routes are defined inline in `server.js`; feature routes are in separate modules under `routes/`.
## Frontend Conventions
- Single-page app with page-level navigation managed in `App.js` (no React Router).
- Auth state managed via React Context (`AuthContext`). Use `useAuth()` hook for login/logout/role checks.
- API calls use `fetch()` with `credentials: 'include'` for cookie-based auth.
- API base URL from `process.env.REACT_APP_API_BASE`.
- Styling uses a mix of inline style objects (defined as constants in component files) and `App.css` global styles.
- Dark theme with a "tactical intelligence" aesthetic — see `DESIGN_SYSTEM.md` for color palette, typography, and component specs.
- Icons from `lucide-react`. Charts from `recharts`.
- Page components live in `components/pages/`. Shared components live in `components/`.
- No TypeScript — the project uses plain JavaScript throughout.

78
.kiro/steering/tech.md
View File

@@ -1,78 +0,0 @@
# Tech Stack & Build System
## Stack
| Layer | Technology |
|-------|-----------|
| Backend | Node.js 18+, Express 5 |
| Database | SQLite3 (file: `backend/cve_database.db`) |
| Auth | bcryptjs, cookie-based sessions (httpOnly, 24h expiry) |
| File uploads | Multer 2 (10MB limit) |
| Frontend | React 19 (Create React App / react-scripts 5) |
| UI Icons | lucide-react |
| Charts | recharts |
| Spreadsheet parsing | xlsx (frontend), pandas + openpyxl (backend Python scripts) |
| Markdown rendering | react-markdown |
| Diagrams | mermaid |
## Common Commands
### Backend
```bash
cd backend
node setup.js # Initialize DB, tables, indexes, default admin user
node server.js # Start backend on port 3001
```
### Frontend
```bash
cd frontend
npm install # Install dependencies
npm start # Dev server on port 3000
npm run build # Production build
npm test # Run tests (react-scripts test)
```
### Both servers (from project root)
```bash
./start-servers.sh # Start backend + frontend in background
./stop-servers.sh # Stop all servers
```
### Database Migrations (run from `backend/` in order)
```bash
node migrations/add_knowledge_base_table.js
node migrations/add_archer_tickets_table.js
node migrations/add_ivanti_sync_table.js
node migrations/add_ivanti_findings_tables.js
node migrations/add_ivanti_todo_queue_table.js
node migrations/add_card_workflow_type.js
node migrations/add_todo_queue_ip_address.js
node migrations/add_compliance_tables.js
```
### Python Scripts (from `backend/scripts/`)
```bash
# Compliance xlsx parsing (called automatically by upload flow)
python3 parse_compliance_xlsx.py <file>
# Bulk notes import
python3 import_notes_from_csv.py input.csv --dry-run
python3 import_notes_from_csv.py input.csv
```
Python dependencies: `pandas>=2.0.0`, `openpyxl>=3.0.0` (install via apt or venv).
## Environment Configuration
- `backend/.env` — PORT, CORS_ORIGINS, SESSION_SECRET, NVD_API_KEY, Ivanti API credentials
- `frontend/.env` — REACT_APP_API_BASE, REACT_APP_API_HOST
- Both `.env` files are gitignored; see `.env.example` files for templates.
- React caches env vars at build/start time — restart the frontend process after changes.
## Default Ports
| Service | URL |
|---------|-----|
| Frontend | http://localhost:3000 |
| Backend API | http://localhost:3001 |