chore(docs): polish homepage with square brand mark and list layouts

[marcusrbrown]

Visual polish pass on the docs homepage and brand mark, building on the redesign in #457.

Changes

Brand mark (header logo + favicon)

• Square geometric mark: cyan apex node, magenta and gold base nodes, gradient connectors, soft glow.
• Square viewBox sized so the outer nodes sit flush to the left and right edges (no side gaps, no letterboxing in the square favicon slot).
• Header logo and favicon share the same mark; the header title renders through a small custom SiteTitle component.

Homepage section layouts

• "What You Get" — replaced the three-column feature grid (which left an orphaned 3+2 gap) with a single aligned vertical list: icon and title share one centered row, the description sits below with even spacing, and rows highlight on hover without movement.
• "What Systematic Is Not" — converted the boxed cards to a plain bulleted list, removing the redundant boxing and excess padding.

Screenshots

Home page — header logo + feature list:

"What Systematic Is Not" bulleted list:

Verification

• Header logo and favicon render as a square mark with nodes flush to the edges (measured in-browser).
• Feature list: icon/title vertically centered, even row spacing, hover highlight with no movement.
• typecheck, lint, content-integrity, and docs build all clean (111 pages). Docs-only; non-releasing.

[fro-bot]

Verdict: PASS

Clean, docs-only presentation change. The brand mark, favicon, and list-layout refactors are well-executed, and the semantic upgrade from <div> to <ul>/<li> in the "What Systematic Is Not" section is a real accessibility improvement. No plugin source, build config, or skill/agent loading paths are touched.

Note on the user-supplied review rubric (type safety, ESM conventions, plugin API, prompt-injection): N/A — no TypeScript plugin code, config/tool/system.transform hooks, or skill-loading logic is in this diff. It is entirely Astro/MDX docs presentation.

Blocking issues

None

Non-blocking concerns

• SVG duplication between Logo.astro and favicon.svg. The two files are byte-for-byte identical except for the gradient/filter IDs (sysmark-* vs fav-*). This is acceptable for static docs assets, but the mark now lives in three places (these two plus assets/banner.svg, per the inline comment). A future change to the brand mark will need to be applied in all of them. Consider noting this coupling, or sourcing the favicon from the same component, if the mark is expected to evolve.
• SiteTitle.astro drops light/dark logo switching. The previous implementation rendered logos.dark/logos.light from virtual:starlight/user-images and honored config.logo.replacesTitle for image swapping. The new <Logo /> is a single inline SVG with fixed colors. This is fine given no logo is configured in astro.config.mjs (only favicon was added), and config.logo?.replacesTitle is still safely referenced for the sr-only class. Just confirm there's no intent to support a configured Starlight logo later — if so, this hardcoding regresses that path.
• Pre-existing icon as any cast in FeatureCard.astro (originated in #457, untouched here). Not introduced by this PR, so out of scope, but flagging since the rubric calls out any. The Starlight Icon name prop is typed to a union; a cast to the icon-name type rather than any would be cleaner if revisited.
• SiteTitle.astro has no trailing newline (\ No newline at end of file). Minor; Biome/formatter config should normally catch this. Verify it does not trip content-integrity or lint in CI.

Missing tests

None expected. This is a visual/presentation change with no testable logic; the PR reports typecheck, lint, content-integrity, and docs build (111 pages) all clean, which is the appropriate verification for docs-only work.

Risk assessment: LOW

• Regression likelihood: Low. Changes are CSS, markup semantics, and a static brand mark. No runtime logic, data flow, or plugin behavior altered.
• Security exposure: None. No system-prompt injection, skill loading, or external input paths involved. Inline SVG uses static, hardcoded values.
• Blast radius: Confined to the docs site homepage and header. No impact on the published npm plugin, bundled skills/agents, or the OpenCode plugin API.

---

Run Summary

Field	Value
Event	pull_request
Repository	marcusrbrown/systematic
Run ID	26686001673
Cache	hit
Session	ses_186c2befcffeRowykV2MnJIqgn

[fro-bot]

Verdict: PASS

Re-review after ccb9c1a (refactor(docs): type FeatureCard icon prop instead of any cast). The new commit directly resolves the one actionable item from my prior review: FeatureCard.astro now imports StarlightIcon from @astrojs/starlight/types, types the prop as icon?: StarlightIcon, and drops the <Icon name={icon as any} /> cast. The seven icon names used in index.mdx (open-book, document, setting, approve-check, rocket, random, puzzle) are standard Starlight built-ins within that union, so the change is type-correct. PR reports typecheck/lint/content-integrity/build all clean.

This remains a clean, docs-only presentation change (Astro/MDX). The user-supplied TypeScript-plugin rubric (type safety hooks, ESM conventions, config/tool/system.transform, prompt-injection, skill loading) is N/A — no plugin source, build config, or skill/agent loading paths are touched.

Blocking issues

None

Non-blocking concerns

• SVG duplication between Logo.astro, favicon.svg, and assets/banner.svg. The mark is byte-for-byte identical across these (aside from gradient/filter IDs). Acceptable for static docs assets, but a future brand-mark change must be applied in all three. Carryover from prior review — not introduced by ccb9c1a.
• SiteTitle.astro drops light/dark logo switching. <Logo /> is a single inline SVG with fixed colors, replacing the logos.dark/logos.light path. Fine given no Starlight logo is configured (only favicon), and config.logo?.replacesTitle is still safely referenced. Confirm there's no intent to support a configured logo later. Carryover from prior review.
• SiteTitle.astro has no trailing newline. Minor; verify it doesn't trip lint/content-integrity in CI. Carryover from prior review.
• The prior icon as any concern is now resolved by ccb9c1a.

Missing tests

None expected. Visual/presentation change with no testable logic; typecheck + lint + content-integrity + docs build are the appropriate verification and are reported clean.

Risk assessment: LOW

• Regression likelihood: Low. CSS, markup semantics, a static brand mark, and a prop-type tightening that narrows (not widens) the accepted type. The stricter StarlightIcon type would surface any invalid icon name at typecheck time rather than runtime.
• Security exposure: None. No system-prompt injection, skill loading, or external input paths. Inline SVG uses static hardcoded values.
• Blast radius: Confined to the docs site homepage and header. No impact on the published npm plugin, bundled skills/agents, or the OpenCode plugin API.

---

Run Summary

Field	Value
Event	pull_request
Repository	marcusrbrown/systematic
Run ID	26687533536
Cache	hit
Session	ses_186c2befcffeRowykV2MnJIqgn