3b4668aea8
mara nit on #1: the three SVGs in static/ were identical copies (md5 1108d7bd79ca…). Dropped favicon.svg + hex-mark.svg; kept hyperhive.svg as the single source. Both consumers now point at it: `<link rel="icon">` and the hero's `load_data(path="static/ hyperhive.svg", format="plain")`. Also fixed: the original `load_data(path="hex-mark.svg")` would have failed at build time anyway — Zola's `load_data` resolves from project root, so files in `static/` need the full prefix + `format="plain"` to come back as raw markup. Build was never validated locally (remote-builder unreachable from agent), so the typo would have surfaced on the operator's first `nix build`. Caught it during the dedupe pass. If a future visual divergence is wanted (simpler favicon, titled og:image), can split back into named copies then.
69 lines
2.7 KiB
HTML
69 lines
2.7 KiB
HTML
{% extends "base.html" %}
|
|
|
|
{% block content %}
|
|
{# Hero — hex motif left, headline + tagline + CTA right. Stacks
|
|
vertically on narrow viewports via the .hero CSS grid. #}
|
|
<section class="hero">
|
|
<div class="hero-art" aria-hidden="true">
|
|
{# Inline so the SVG inherits the page's font + can be styled
|
|
(hover pulse animation on the rings). Same source as the
|
|
dashboard branding/hyperhive.svg — single canonical copy at
|
|
static/hyperhive.svg drives favicon + og:image + hero inline.
|
|
If a future visual divergence is wanted (smaller favicon,
|
|
titled og:image), split into named copies then.
|
|
`format="plain"` returns the raw markup string instead of
|
|
parsing the SVG as XML. #}
|
|
{% set hex_svg = load_data(path="static/hyperhive.svg", format="plain") %}
|
|
{{ hex_svg | safe }}
|
|
</div>
|
|
<div class="hero-text">
|
|
<h1>
|
|
<span class="banner-glyph">░▒▓</span>
|
|
hyperhive
|
|
<span class="banner-glyph">▓▒░</span>
|
|
</h1>
|
|
<p class="hero-tagline">{{ config.description }}</p>
|
|
<p class="hero-cta">
|
|
<a class="cta-primary" href="http://localhost:3000/hyperhive/hyperhive">
|
|
◆ explore the code →
|
|
</a>
|
|
</p>
|
|
</div>
|
|
</section>
|
|
|
|
{# Landing prose — pulled from _index.md so non-engineers can edit
|
|
copy without touching templates. #}
|
|
<section class="prose">
|
|
{{ section.content | safe }}
|
|
</section>
|
|
|
|
{# Three-column "what's inside" — quick orientation for visitors
|
|
who clicked through from a link without context. Copy here is
|
|
intentionally short; deep dives belong in /docs (future). #}
|
|
<section class="grid-3">
|
|
<article class="card">
|
|
<h2><span class="card-glyph">▣</span> the swarm</h2>
|
|
<p>
|
|
Each agent is a NixOS container with its own claude session,
|
|
a logical name, and a parent in the topology tree. Containers
|
|
come and go; the topology is the operator's facts file.
|
|
</p>
|
|
</article>
|
|
<article class="card">
|
|
<h2><span class="card-glyph">⟁</span> the dashboard</h2>
|
|
<p>
|
|
One web page shows live agent state, the broker stream, the
|
|
approval queue, scheduled prompts, and the rebuild pipeline.
|
|
Everything that mutates the swarm passes through here.
|
|
</p>
|
|
</article>
|
|
<article class="card">
|
|
<h2><span class="card-glyph">◇</span> the boundary</h2>
|
|
<p>
|
|
Agents can ask, schedule, request approvals, and message peers
|
|
— but never spawn / destroy / mutate config themselves. Those
|
|
actions queue up and wait on the human at the dashboard.
|
|
</p>
|
|
</article>
|
|
</section>
|
|
{% endblock %}
|