Operating principle: new pages should either help a defender decide, validate, communicate, or act. If a feature does not support one of those outcomes, it should stay in notes until it has a clearer job.
Quality Center
Keep the portal useful, trustworthy, and calm as it grows.
Use this page before and after large batches. It turns product quality, release checks, content governance, and manual QA into a repeatable workflow.
1Run diagnosticsCheck route wiring, containers, runtime state, and launch readiness.
2Manual QAUse the browser checklist for desktop, mobile, tools, map, and detail flows.
3Govern contentKeep category balance, route purpose, and page ownership consistent.
4Choose next workPick the next batch from quality-first priorities instead of feature sprawl.
Release Gates
Do not ship a large batch until these checks are healthy
Automated
Local checker passes
Run powershell -ExecutionPolicy Bypass -File scripts/check-site.ps1. It should pass links, IDs, metadata, JS imports, route containers, route metadata, page heroes, and navigation coverage.
Manual
Critical paths reviewed
Open Home, Start Here, Threat Map, Tools, Search, Saved, Compare, one detail page, one strategic hub, Status, and Diagnostics at desktop and mobile widths.
Trust
Data states are honest
Every live-derived page should clearly distinguish loaded data, unavailable API state, filtered-empty state, and analyst assumptions.
Methodology
Risk language is explainable
Users should be able to understand how action labels, trust caveats, live-derived views, and validation steps are meant to be interpreted.
UX
No page feels like a dead end
Each page should have a clear next action: open a queue, pivot to a tool, save/compare, check trust, or return to a broader hub.
Trust transparency
Public limits are easy to find
Known limitations, data freshness, feed transparency, responsible use, headers, and security contact checks should be visible before public launch.
Performance
Growth stays visible
Diagnostics should show route scale, loaded payload estimates, session cache state, image health, and local timing hints after large batches.
Post-Batch Review
Use this when a batch changes how people find their way around
Discovery
Open the route choosers
Check Workflows and Site Map first. The chooser cards should route by known term, situation, role, output, practice goal, trust question, and full inventory.
Returning users
Explain what changed
What's New should name the batch, show where to resume, and tell users which checks matter after the change.
Workflow fit
Follow one real path
Pick one scenario and follow it from chooser to hub to page to output. The route should feel shorter than browsing the dropdowns.
Guardrails
Check docs drift
Discovery docs, next priorities, and the manual matrix should describe the current routing model before another navigation batch starts.
Large Batch Mode
How to change several surfaces without losing product quality
Scope
Name the theme first
A big batch should still have one theme: trust wording, tool workflow, beginner learning, mobile QA, release readiness, or content depth. Avoid unrelated feature piles.
Touchpoints
Update the public path and the guardrail
When a batch changes behavior, update the page, shared module, route metadata, docs, and automated checks if a future regression would be easy to miss.
Verification
Automate broad, manually test narrow
Run release prep for the whole site, then manually test only the workflows that changed: map, tools, status, detail, navigation, or export/copy behavior.
Handoff
Leave a clear review trail
Summarize what changed, which files matter, what passed, and what still needs public-domain verification such as sitemap generation or deployed headers.
Training App Review
Check the Games, Coach, Report, and Android wrapper loop together
Practice loop
Choose, play, continue, report
Review Games Hub, App Home Preview, Training Coach, Practice Packs, Mini-Game Player, Game Progress, Training Report, Daily Challenge, and Scenario Library as one route.
Local state
Progress stays device-first
Coach profile, game progress, daily state, pack progress, and report output should persist in browser or WebView local storage without implying an account.
Cloudflare APIs
Shared site/app data is safe JSON
Check /api/app-home, /api/games/coach, /api/games/packs, /api/games/scenarios, /api/games/daily, and /api/health on the deployed origin for clear fallback wording, app-contract metadata, and no secret exposure.
Android wrapper
Validate in Android Studio
The app should open App Home Preview, expose the horizontal quick rail, keep internal links inside the WebView, and preserve local training state across restarts.
Runbook route
Practice has operating paths now
Review Runbook Index, Daily Workflow, Daily Standup, and Weekly Review so training and Android app review are discoverable without implying certification, compliance, identity proof, or live remediation evidence.
Diagnostics
Runtime contract is visible
Use Diagnostics to confirm the Android WebView shell marker, device ID seed, expected local-storage keys, Health metadata, and app-facing API links before treating the app loop as ready.
Content Rules
The editorial guardrails that keep the site beginner-friendly
One page, one job
Every page should answer a distinct question. If two pages answer the same question, one should become a hub and the other should become a deeper drill-down.
Explain live-derived views
Maps, actor context, ransomware relevance, and exploit-chain views should clearly say when they are inferred from loaded data rather than direct telemetry.
Prefer action labels
Use language like Patch Now, Mitigate First, Validate Exposure, Watch, Draft Detection, and Escalate instead of only severity labels.
Keep beginner paths visible
Start Here, Daily Workflow, Site Map, Learn, Status, and Diagnostics should remain easy to find even as advanced pages grow.
Route Governance
Keep category balance intentional before adding pages
Balance
Core should stay rare
Use Core for orientation, decision surfaces, evidence, handoff, and governance. Put practice in Training and slower interpretation in Research before adding another Core page.
Training
Practice belongs in drills
Scanner validation, advisory reading, evidence packets, closure decisions, and leadership updates should become Training when the user is rehearsing judgment.
Research
Interpretation belongs in references
Source differences, vendor/product patterns, evidence quality, methodology, and analytics should live in Research when the page compares rather than commands.
Discovery
New pages need natural entry paths
After a new route lands, update Start Here, Site Map, related next-action bands, route metadata, and release notes so users are not forced to rely on the dropdown.
Output-First Review
Check whether users can start from the artifact they need
Evidence packet
Can users validate before action?
Start Here, Search, Site Map, and Runbook Index should route scanner findings, affected-version questions, not-affected claims, and closure proof into validation and evidence-quality pages.
Handoff
Can users reach the right owner message?
Patch, SOC, asset-owner, vendor, risk, and leadership communication should be reachable without knowing exact page names.
Decision
Can users pick a lane quickly?
Patch, mitigation, detection, validation, monitoring, escalation, exception, and not-affected decisions should point to one clear next page.
Brief
Can users explain progress safely?
Daily, weekly, executive, and stakeholder updates should preserve evidence quality, caveats, owners, blockers, and next review dates.
Governance
Can users review risk and quality?
Exception, metrics, readiness, maturity, and release-quality pages should make weak proof, stale data, and category drift visible.
Practice
Can users rehearse safely?
Practice-oriented work should route to Training drills rather than adding more Core explanation pages.
Editorial Audit
Find pages that need tightening before adding more content
Purpose
One page, one defensible job
Review pages that feel like broad explanations. Each page should state the user question, the expected output, and the next action without becoming a second Site Map.
Duplication
Merge repeated mental models
If two pages explain the same concept, keep one as the hub and turn the other into examples, templates, or a role-specific drill-down.
Voice
Keep claims calm and operational
Prefer concrete phrases like validate exposure, confirm affected versions, choose owner, collect closure proof, and preserve caveats.
Density
Shorten pages that feel like walls
Long pages should use cards for decisions, examples, checklists, or copy-ready outputs. If a page is mostly prose, split it into a guide plus examples.
Discovery
Every deep page needs a natural path
A deep page should be reachable from Start Here, Site Map, Runbook Index, Role Paths, a strategic hub, a detail page, or a related tool.
Evidence
Examples should show proof boundaries
Scenario and example pages should name what Vuln Signal can suggest, what needs local proof, and what belongs in official systems.
Content Triage Lanes
Use these labels when deciding what to improve next
Fix first
Confusing, risky, or misleading
Prioritize pages with unclear trust language, weak proof boundaries, broken pivots, stale public-domain instructions, or missing next actions.
Consolidate
Useful but repetitive
Pages that repeat another workflow should either become examples, move into a hub, or link more clearly to the canonical explanation.
Expand
Useful but too thin
Pages that answer a real question but lack examples should get scenario cards, copy-ready output, or a short validation checklist.
Promote
High-value but hidden
Pages that solve common work should be added to Site Map paths, Role Paths, Runbook Index, Start Here, or related detail/tool pivots.
Visual Audit
Check layout quality before adding more UI surface
Density
Cards should scan, not compete
Check that headings stay short, paragraphs fit in two to four lines, and related cards have similar visual weight.
Mobile
No sideways layout pressure
At phone width, cards, tool outputs, filters, map summaries, and action buttons should stack without page-wide horizontal scroll.
Actions
Buttons should describe real commands
Primary buttons should open or copy the next useful thing. Secondary links should pivot, not decorate the card.
States
Empty and degraded views need shape
Loading, empty, demo, unavailable, filtered, and stale states should look intentional and explain what changed.
Text Fit
Long labels must wrap cleanly
Pills, buttons, dropdowns, filter chips, table cells, and tool output should not clip, overlap, or push other content off-screen.
Briefing pages should survive print
Print preview should hide navigation and controls while keeping briefing, workflow, and evidence cards readable.
Manual Test Matrix
The fastest useful QA pass after changes
Navigation
Top menu, dropdowns, mobile menu
Check hover/focus, six-door top navigation, curated dropdowns, right-edge alignment, mobile toggle, and active states.
Live Data
Loaded, empty, and unavailable states
Check Home, Threat Map, CVEs, Advisories, Status, and strategic hubs when the API succeeds or fails.
Workflow
Details, saving, compare, and handoff
Open a record, save it, add a note, compare it, and copy a remediation or SOC handoff summary.
Tools
Inputs, outputs, copy buttons, overflow
Try one parser, one calculator, one lookup, one detection helper, and one formatter on desktop and mobile.
Improvement Backlog
What to prioritize next when the site feels stable
Make flows measurable
Add visible freshness, coverage, and confidence summaries to more pages so users know whether a view is ready for decisions.
Watch payload growth
Use Diagnostics after major content, search, or route batches to check loaded-record size, static search-index behavior, local workflow storage, and render timing hints.
Improve maturity deliberately
Use the Maturity Model to choose one weak capability at a time instead of adding unrelated features.
Reduce duplicate mental models
Use shared guidance modules, route metadata, and Site Map paths before adding new standalone explanation sections.
Strengthen tool privacy notes
Keep local-only tools clearly labeled, and make backend-assisted lookups explicit when network calls are required.
Expand QA automation carefully
Next automated checks should focus on navigation coverage, renderer/container alignment, and docs drift before visual automation.
Recommended next move: after a big content or UI batch, open Diagnostics first, then run the manual matrix only on the critical workflows that changed.