shd.build/.impeccable/critique/2026-07-26T15-49-23Z__src-routes.md

target, total_score, max_score, na_heuristics, p0_count, p1_count, timestamp, slug

target	total_score	max_score	na_heuristics	p0_count	p1_count	timestamp	slug
application route system	28	40		0	2	2026-07-26T15-49-23Z	src-routes

SHD.build route-system critique

Design Health Score

#	Heuristic	Score	Key issue
1	Visibility of system status	4	ISAC exposes environment, access, mode, active navigation, and filter state clearly.
2	Match system / real world	3	SHD vocabulary is authentic, but codes such as OSPR and WMOD need plain-language support.
3	User control and freedom	3	Navigation and cancellation patterns are strong; empty destinations and filter clearing are less explicit.
4	Consistency and standards	3	Shared patterns are cohesive, but live search plus Search, static-looking KPI links, and Edit-only rows diverge.
5	Error prevention	3	Guardrails are extensive, but Add/Edit consequence language is not visible before entry.
6	Recognition rather than recall	2	Seventeen ISAC destinations, code labels, and visually identical category cards create scanning burden.
7	Flexibility and efficiency	3	Search, filtering, page sizes, and grouped navigation help experts; one-page registries expose unnecessary controls.
8	Aesthetic and minimalist design	2	The system is disciplined, but cinematic hero scale and equally weighted bordered blocks compete with the task.
9	Error recovery	3	The application has designed error and preservation patterns, though recovery was not exercised in the inspected states.
10	Help and documentation	2	Microcopy exists, but ISAC terms, permissions, and proposal consequences lack contextual help.
Total		28/40	Good foundation; focused hierarchy and disclosure work needed.

Design Specificity Verdict

The result is strongly authored for SHD.build. Black/graphite command surfaces, orange targeting rails, angular hero cuts, coded modules, explicit system state, and ISAC terminology form a convincing Division intelligence network. The identity becomes less specific where repeated bordered registry cards and KPI blocks flatten into a generic dark administrative grid.

The deterministic scan found seven source findings across src/routes: one warning for the two-pixel semantic notification rail in src/routes/account/+page.svelte, and six advisory colors outside the documented palette in the homepage and account route. The rail is largely a detector false positive because it conveys semantic message state, but its colors should still come from named tokens. The homepage build colors are data-like values rather than structural CSS, yet they also bypass the maintained palette.

Mutable browser injection was unavailable, so no visual overlay is claimed. Fresh Chrome tabs, screenshots, DOM snapshots, and computed styles instead confirmed no horizontal overflow and no visible text below 12px on the public Database or ISAC Attributes pages.

Overall Impression

SHD.build already feels unusually coherent and product-specific. Its biggest opportunity is to let that identity guide attention rather than compete for it: the public Database should reach useful records sooner, and ISAC should reveal its complexity according to the operator's current task and role.

What's Working

1. The visual language is specific, restrained, and thematically credible. Orange remains primarily an action/current-state signal, and textual state accompanies color.
2. Shared structures such as KPI filters, registry pagination, database-card anatomy, and the ISAC shell make the large application feel related rather than stitched together.
3. Baseline semantics are strong: named navigation, headings, search labels, aria-current, disabled-state semantics, and explicit status text are present in the inspected DOM.

Priority Issues

P1 — ISAC exposes the entire system before the current task

The Attributes screen simultaneously presents 17 sidebar destinations, four system-state blocks, four KPI filters, search, pagination, row-size controls, six table columns, and repeated Edit actions. Experienced operators can scan it, but contributors and new Oversight users must decode the whole information architecture before acting.

Fix: make sidebar groups collapsible, prioritize modules by role and recent work, hide pagination controls when one page is present, and preserve a compact module switcher/search for experts.

Suggested command: $impeccable distill

P1 — Mutation consequences are not visible at the decision point

The interface knows whether an operator publishes directly or creates a review proposal, but the registry's Add/Edit actions do not state that consequence. This is a high-stakes ambiguity for contributors and Oversight.

Fix: place a role-aware consequence line beside the module action and repeat it in the editor header: either “Creates a proposal for Oversight review” or “Publishes directly and creates an audit event.”

Suggested command: $impeccable clarify

P2 — The Database hero delays the lookup task

At the inspected 4K viewport the 82px, two-line hero occupies roughly a 333px-tall surface, and the category grid starts around 563px down the page. “Contribute data” is visually louder than registry discovery even though lookup is the common task.

Fix: retain the angular tactical hero but reduce its vertical commitment, move useful category identity into the first viewport, and demote contribution to a clear secondary path.

Suggested command: $impeccable layout

P2 — Empty registries promise the same value as populated registries

Four of eight Database cards show zero records and “Awaiting contributions,” but look and behave like full destinations. That creates repeated anticipation followed by a low-value endpoint.

Fix: give empty registries an explicit empty-state anatomy with expected content, contribution action, and availability state. Keep them visible, but do not imply the same outcome as populated data.

Suggested command: $impeccable onboard

P2 — Functional contrast and interaction grammar remain uneven

Muted database descriptions, inactive navigation, unit sublabels, and pagination text recede heavily. KPI filters resemble static metrics, table rows look selectable while only the small Edit action works, and a Search button remains beside an input that searches as the user types.

Fix: reserve the dimmest tone for nonessential metadata, raise informative copy and available navigation one contrast step, make KPI filter state unmistakably interactive, align desktop row behavior with mobile, and remove or reframe redundant Search controls.

Suggested command: $impeccable polish

Cognitive Load

Five checklist failures indicate high load on ISAC: insufficient progressive disclosure, too many simultaneous paths, competing hierarchy, repeated low-information choices, and excessive visible controls for one-page results. Grouping itself is good, but several decision points exceed working-memory limits: six global destinations, eight Database categories, 17 ISAC modules, seven-plus pagination/search controls, and 22 repeated Edit actions.

Emotional Journey

The Database hero creates a confident, premium entry peak. Populated cards promise useful intelligence, but visually equal empty categories produce a disappointment valley. ISAC's “Online / Authorized / Admin” state reassures operators, then the uniform density creates fatigue with little calm focus. The most important missing reassurance is a plain statement of what Add/Edit will do to live data.

Persona Red Flags

Alex, experienced optimizer: the Database adds a cinematic layer before facts, empty destinations interrupt rapid lookup, and one-page registries retain unnecessary pagination controls. Recent registries, global data search, and role-aware shortcuts would accelerate expert use.

Sam, keyboard and low-vision operator: semantics and focus foundations are strong, but faint functional text and dozens of repeated Edit actions increase navigation cost. KPI links need clearer control semantics, and role/consequence state should be announced before mutation.

Maya, first-time mobile agent: ISAC, OSPR, WMOD, Oversight, registry, and resolved attributes assume insider fluency. Category icons, plain-language supporting labels, and meaningful empty states would reduce abandonment.

Minor Observations

• Database categories need stronger visual identity; icons would aid recognition and make the incomplete final grid row feel intentional.
• The record total “15” can overstate breadth while half the registries are empty; “4 registries online · 15 records” sets expectations better.
• Unit values such as % and NO UNIT are hard to associate with the attribute name at a glance.
• Module-count headers add telemetry but do not always improve task choice.
• The maintained design sidecar is stale relative to DESIGN.md.

Questions to Consider

• Is the Database index primarily a cinematic gateway or a fast lookup tool?
• Should empty registries be destinations, contribution prompts, or roadmap teasers?
• If ISAC already knows role and mode, why should every operator receive the same full module navigation?
• What single sentence must a contributor understand before selecting Add?