Finalize Rivets design and challenge learning experience

.env.example

@@ -1,5 +1,10 @@
 # Copy to .env.local and fill in. Never commit .env.local.
 
+# --- App label ------------------------------------------------------------
+# Visitor-facing prototype label. Organization, package imports, and URLs stay
+# Roughstack; changing this value and rebuilding updates navigation + metadata.
+NEXT_PUBLIC_PLATFORM_NAME="Rivets"
+
 # --- Database -------------------------------------------------------------
 # Host-side value. Inside docker compose the web service overrides the host to
 # `postgres`, since that is the service name on the compose network.

CONTRIBUTING.md

@@ -1,6 +1,6 @@
-# Contributing to Rough Stack
+# Contributing to Roughstack
 
-Thank you for helping build Rough Stack. Contributions should keep the platform
+Thank you for helping build Roughstack. Contributions should keep the platform
 reproducible, reviewable, secure around untrusted code, and independent from
 private official-evaluation material.
 

LICENSE

@@ -186,7 +186,7 @@
       same "printed page" as the copyright notice for easier
       identification within third-party archives.
 
-   Copyright 2026 Rough Stack contributors
+   Copyright 2026 Roughstack contributors
 
    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.

NOTICE

@@ -1,4 +1,4 @@
-Rough Stack
-Copyright 2026 Rough Stack contributors
+Roughstack
+Copyright 2026 Roughstack contributors
 
 This product is licensed under the Apache License, Version 2.0.

README.md

@@ -1,13 +1,21 @@
-# Rough Stack
+# Roughstack web platform
 
-An interactive coding platform and secure evaluation engine for **systems engineering**
-challenges. Not another algorithm quiz site: you implement real storage and hardware
-internals, and your solution is graded on the metrics engineers actually argue about.
+The visitor-facing app currently prototypes the name **Rivets**. The
+organization and repository names remain Roughstack. Set
+`NEXT_PUBLIC_PLATFORM_NAME` before building to try a different label; the
+navigation, footer, and metadata read it from one place in `src/lib/brand.ts`.
+The symbol is separate from that label. Its shared source is
+`src/components/brand-mark.tsx`, including the generated browser icon.
 
-The first challenge asks you to write the data-movement policy for a simulated NAND
-flash device. Your code is scored on write amplification, erase count, and wear evenness
-against a synthetic workload of thousands of operations, then attacked with injected
-hardware faults to see whether the logic actually holds up.
+An interactive coding platform for **systems engineering** challenges. You implement
+storage and systems internals, run them against deterministic workloads, and inspect
+the resulting behavior. Generated challenges currently provide practice feedback;
+their zero-valued scores are not a ranking system.
+
+The original SSD challenges ask you to write policies for a simulated NAND flash
+device. Those challenges measure write amplification, erase count, and wear evenness
+against synthetic workloads and injected faults. The newer Go practice challenges
+cover caching, queues, scheduling, logs, and related systems concepts.
 
 The current open-source runtime executes submissions through a local Docker
 backend. A synthetic stub is available for UI development. Durable judging,
@@ -182,5 +190,5 @@ docs/
 
 ## License
 
-Rough Stack is licensed under the [Apache License 2.0](LICENSE). See
+Roughstack is licensed under the [Apache License 2.0](LICENSE). See
 [NOTICE](NOTICE) for attribution information.

SECURITY.md

@@ -1,6 +1,6 @@
 # Security policy
 
-Rough Stack executes participant-controlled code. Reports involving sandbox
+Roughstack executes participant-controlled code. Reports involving sandbox
 escape, path traversal, secret exposure, authentication bypass, result forgery,
 queue corruption, denial of service, or private-evaluation leakage must be
 handled privately.

SUPPORT.md

@@ -6,7 +6,7 @@
 - Use `SECURITY.md` for vulnerabilities; never publish exploit details in an
   issue.
 
-Rough Stack is community-maintained software. Support is best effort and does not
+Roughstack is community-maintained software. Support is best effort and does not
 include service-level guarantees. Include operating system, runtime versions,
 the exact revision, relevant logs with secrets removed, and minimal reproduction
 steps when asking for help.

docs/adr/0001-arena-repository-boundaries.md

@@ -5,7 +5,7 @@
 
 ## Context
 
-Rough Stack needs to support multiple independently evolving systems arenas without
+Roughstack needs to support multiple independently evolving systems arenas without
 turning the web application and judge into a collection of arena-specific branches.
 Official evaluation also needs hidden workloads and reference material that must
 never enter a public build.
@@ -16,7 +16,7 @@ evaluation material to leak into a public image or artifact.
 
 ## Decision
 
-Rough Stack uses three repository boundaries:
+Roughstack uses three repository boundaries:
 
 1. `bytearena` is the public platform repository. It owns contracts, discovery,
    validation, scoring primitives, the web/control plane, judge worker, execution
@@ -30,8 +30,8 @@ Rough Stack uses three repository boundaries:
 The dependency direction is one-way:
 
 ```text
-bytearena-arenas  ──uses──> versioned Rough Stack contracts and SDK
-bytearena-official ─uses──> versioned Rough Stack contracts and public arena identity
+bytearena-arenas  ──uses──> versioned Roughstack contracts and SDK
+bytearena-official ─uses──> versioned Roughstack contracts and public arena identity
 bytearena          ─loads──> immutable arena bundles through public contracts
 ```
 

docs/adr/0002-repository-responsibilities.md

@@ -15,7 +15,7 @@ deployments and gives public repositories names that do not describe their conte
 
 ## Decision
 
-Rough Stack uses four repositories with explicit responsibilities:
+Roughstack uses four repositories with explicit responsibilities:
 
 1. `roughstack/web-platform` contains the website, editor, accounts, discussions,
    submissions, database schema, control plane, and deployment configuration.

docs/dependency-policy.md

@@ -1,6 +1,6 @@
 # Dependency policy
 
-Rough Stack treats dependency maintenance as part of its security posture.
+Roughstack treats dependency maintenance as part of its security posture.
 
 ## Requirements
 

docs/design-exhibition.md

@@ -0,0 +1,54 @@
+# Rivets: computing exhibition
+
+Active visual direction, 16 October 2026. This supersedes the palette and page compositions in `design-system.md`; its accessibility and interaction requirements still apply.
+
+## Intent
+
+Computer science presented with the visual confidence of an exhibition identity. The audience is curious, technical, and comfortable with complexity. Avoid school-workbook styling: no graph paper, decorative schematic corners, dotted backdrops, or ubiquitous pastel cards. Actual axes, memory slots, and data relationships remain where they explain a concept.
+
+## Tokens
+
+| Role | Value |
+| --- | --- |
+| Exhibition dark | `#282334` |
+| Reading paper | `#f2f0ed` |
+| Signal orange | `#ff784f` |
+| Electric lilac | `#b9a1ff` |
+| Mint | `#a9e8cb` |
+| Dark text | `#252231` |
+
+Bricolage Grotesque carries the large, compact headlines. Inter carries explanations. JetBrains Mono is reserved for scores, counts, addresses and code. White text sits on aubergine; aubergine text sits on the bright colors. Do not use white body text on orange or lilac.
+
+## Composition
+
+```text
+HOME       dark navigation / monumental headline + moving storage cutaway
+           orange action / journal recovery story on an acid-lime field
+           paper reading surface / large subject illustrations
+
+DASHBOARD  lilac workbench header / oversize completion counter
+           dark next-experiment panel / colored progress segments
+           illustrated challenge collection / light submission history
+
+RANKINGS   dark score-board header / orange focal type
+           three leading results as large typographic panels
+           light table / clear numeric hierarchy
+```
+
+Color blocks, scale contrasts, asymmetry and custom geometry provide character. Borders and rounded cards should not be the primary source of hierarchy. Keep text left-aligned and preserve open space around the single focal element in each section.
+
+## Mark and illustration
+
+The identity is a modular R: a vertical spine, an open bowl, and a detached diagonal leg. It suggests construction and decomposition, remains recognizable at favicon size, and is independent of the configurable platform name. Navbar and favicon share the same SVG source.
+
+Challenge art uses saturated flat grounds without wallpaper. Difficulty variants differ in shape as well as color. Within the two-column storage collection, card grounds vary across each row and down adjacent rows. The landing storage machine is a conceptual illustration, not a scored run.
+
+## Motion and review
+
+### Landing: motion without a manual
+
+The palette and modular R at `design-exhibition-baseline-2026-10-16` are the approved checkpoint. The hero is a conceptual storage cutaway: violet layers (#7954ef), hot-pink writes (#ff4ba0), cyan routes (#53d9ff), and lime cells (#b7ff45) against plum (#282334). It runs when visible without controls or explanatory overlays. The green completion tick was removed after visual review. Pause animation offscreen and render static art when reduced motion is requested.
+
+The second vignette asks how a file survives an interrupted write. A journal, power interruption, and recovered file sit on a violet illustration field within an acid-lime section. Brief copy leads to the crash-recovery challenge. It is an illustration, not an executable simulation.
+
+Keep the Bricolage headline, readable body typography, left-aligned copy, open composition, and modular logo. Subject cards can respond to hover or focus with subtle motion. Review the homepage, library, dashboard, leaderboard, and both cache difficulty cards on desktop and phone sizes. Verify keyboard focus, contrast, reduced motion, and responsive layout. A passing build does not establish aesthetic quality.

docs/design-system.md

@@ -0,0 +1,176 @@
+---
+title: Rivets visual design system
+status: active implementation specification
+updated: 2026-10-16
+scope: public site, challenge discovery, progress, rankings
+supersedes: visual-direction.md
+---
+
+# Rivets design system
+
+> The active art direction is now [Computing exhibition](design-exhibition.md). The earlier palette and compositions below are retained as design history; accessibility and truthful interaction requirements still apply.
+
+Read this before changing the public UI. The product teaches computer science
+through implementation. Its audience is curious enough to open a computer and
+ask how it works, but does not necessarily know the vocabulary yet. The first
+impression should invite that curiosity; the workspace should sustain it.
+
+## Direction: a science magazine you can operate
+
+A large, original illustration and confident typography establish the first
+impression. A short interaction reveals an idea inside the illustration.
+Explanations, controls, and results become more detailed as a learner proceeds.
+The landing page is an invitation; it does not need to show the entire lesson.
+
+The previous dark half-adder panel is not the visual direction. Its density,
+tiny labels, nested rectangles, and truth table made the hero feel like a
+diagnostic console. Correct behavior alone is not visual acceptance.
+
+Keep the challenge library's domain grouping. Give difficulty variants visibly
+different art while retaining the family's visual identity. Dashboard and
+leaderboard should use the same type and color language, with real data taking
+the place of decorative statistics.
+
+## Reference observations and decisions
+
+| Reference | Observed principle | Rivets application |
+| --- | --- | --- |
+| [MIT Technology Review, Pentagram](https://www.pentagram.com/work/mit-technology-review) | Flexible grid; a few large visual ideas; distinct display, reading, and caption roles; bright color balanced by open space. | One dominant hero image; large unbroken headline; quiet descriptions; captions attached to the visual they explain. |
+| [Thinking Machines Lab](https://thinkingmachines.ai/) | Narrow readable text measure and unusually generous space around its identity. | Limit supporting copy to about 55–65 characters per line. Leave real space around the hero rather than filling it with status badges. |
+| [Muriel Cooper, Pentagram](https://www.pentagram.com/work/muriel) | Typography and motion can express the behavior of information. | Animate a change in memory position; keep the values identifiable during the movement. |
+| [Quanta art direction, Olena Shmahalo](https://www.olenashmahalo.com/project/quanta) | Scientific concepts provide subjects for editorial illustration. | Draw a specific mechanism with a clear silhouette. Do not use random circuitry as a substitute for an idea. |
+
+These are principles, not assets to reproduce. The following tokens and recipes
+are original project decisions. Taste still requires a rendered review.
+
+## Tokens
+
+```yaml
+palette:
+  paper: '#f8fafc'       # cool light canvas, dominant surface
+  ink: '#172730'         # reading and outlines
+  cobalt: '#2447e7'      # primary action, one dominant illustration mass
+  coral: '#f27657'       # contrasting illustration mass, not small text
+  pollen: '#f4ce57'      # supporting illustration mass
+  mist: '#e4eafb'        # quiet structure and secondary surfaces
+type:
+  display: Bricolage Grotesque
+  body: Inter
+  technical: JetBrains Mono
+  hero: 'clamp(3.2rem, 6.8vw, 6.4rem); 0.98 line-height; -0.055em tracking'
+  section: 'clamp(2rem, 3.8vw, 3.6rem); 1.05 line-height'
+  body_size: '16–18px; 1.55–1.65 line-height'
+  caption: '12–14px; 1.4 line-height'
+layout:
+  max_width: 1152px
+  gutter: '20px phone, 32px desktop'
+  section_gap: '64px phone, 96px desktop'
+  reading_measure: 65ch
+motion:
+  response: 180ms
+  spatial_transition: 600ms
+  reduced_motion: immediate state change
+```
+
+Use at least two thirds light or neutral space in a typical viewport. Saturation
+belongs primarily to illustration and the main action. Coral and yellow are
+surfaces, not body-text colors. Labels must pass contrast checks on their actual
+background. Do not put a gradient wash behind every section.
+
+Display type carries the invitation. Body type carries explanation. Monospace
+is reserved for code, addresses, counts, and state. Keep full headlines one
+color and one family. Do not turn every caption into tracked uppercase text.
+
+## Page composition
+
+### Landing page
+
+```text
+brand                                      navigation / start
+
+Large, short headline       One oversized sculptural memory illustration
+Two lines of explanation    Values and spaces are immediately distinguishable
+One clear primary action    One action; one sentence explains the result
+
+Featured challenges: three distinct subjects with short descriptions
+
+One small experiment + explanation of how to learn here
+```
+
+The hero illustration is an isometric memory ribbon with visible gaps and
+colored blocks. Its shape must be interesting before interaction. Compaction
+moves the same values into the first available positions, preserving their
+order; a reset restores the scattered state. This is a conceptual illustration,
+not an execution result. Do not add a fake terminal, fake live statistics, or
+another table inside it.
+
+Remove sections that restate the same promise. A visitor should reach the
+challenge choices within roughly two desktop viewports. The entire front page
+does not need to list every future topic. Neural-network content remains a
+future direction until a real exercise exists.
+
+### Challenge variants
+
+Family determines silhouette; difficulty changes palette and an actual detail.
+For Cache Pressure, Easy uses green with two equal blocks. Medium uses violet
+with unequal blocks and a small clock motif, reflecting variable sizes and
+expiry. Difficulty remains a text badge. Color alone must not identify a tier.
+Unknown slugs continue to receive usable artwork and a normal challenge link.
+
+### Dashboard
+
+Treat the page as a personal workbench: a compact editorial heading, a useful
+next action, followed by genuine progress and history. Empty state uses a small
+memory composition and a direct link to a first challenge. Never invent streaks,
+completion percentages, scores, or sign-in capabilities.
+
+### Leaderboard
+
+Use a strong heading and compact comparison motif above a legible table. The
+data must remain primary. Distinguish the current session and leading ranks
+with restrained color. Explain which challenges are ranked without filling the
+header with implementation details. A decorative motif must not imply real
+rankings when there are no results.
+
+## Illustration construction
+
+- Start with a silhouette that reads at thumbnail size. At most three major
+  color masses should compete in one illustration.
+- Use consistent geometry: one projection, one light direction, one stroke
+  scale. Align connectors to shapes; do not leave near-misses or arbitrary bends.
+- Use depth to separate parts, not as a background effect. Avoid blur clouds,
+  fake glass, and glossy panels around otherwise flat diagrams.
+- Keep labels outside the main shapes when possible. The page caption can
+  explain a metaphor without placing a paragraph inside the art.
+- Preserve object identity through motion. Animate only a learner-triggered
+  transformation; retain a useful static view with reduced motion.
+- Prefer code-native SVG for diagrams that change state. Raster art is suitable
+  for editorial imagery when it adds a visual quality SVG cannot supply.
+
+## Review gate
+
+Review the rendered page at 390px, 768px, and 1440px, plus the 320px overflow
+check. Ask these questions separately from automated tests:
+
+1. Is there one obvious focal point within three seconds?
+2. Does the image have a deliberate silhouette, color balance, and negative space?
+3. Does the headline read naturally without awkward one-word orphan lines?
+4. Can the idea be understood before reading the small caption?
+5. Does interaction produce a visible, meaningful change?
+6. Can Easy and Medium be distinguished at thumbnail size?
+7. Do progress and ranking views belong to the same visual family?
+
+Reject a design if any of the first five answers is no. Review screenshots,
+not just the source. Test contrast, overflow, keyboard access, and reduced motion
+as functional gates; passing them is not evidence of aesthetic quality.
+
+## Contributor continuation
+
+Implementation order: tokens and reusable illustration, landing composition,
+variant art, dashboard and leaderboard, then visual review and focused checks.
+Keep changes in atomic commits. Preserve the existing baseline tag
+`visual-baseline-before-bold-cs-2026-10-16` for comparison.
+
+When revising this guide, update the tokens, recipes, and review criteria in
+place. Record stable design decisions, not assistant transcripts. Link this
+guide from older design notes so a future contributor has one source of truth.