Sync from evaleval/eval-cards via hub-sync

.claude/skills/adapt

@@ -1 +0,0 @@
-../../.agents/skills/adapt

.claude/skills/animate

@@ -1 +0,0 @@
-../../.agents/skills/animate

.claude/skills/arrange

@@ -1 +0,0 @@
-../../.agents/skills/arrange

.claude/skills/audit

@@ -1 +0,0 @@
-../../.agents/skills/audit

.claude/skills/bolder

@@ -1 +0,0 @@
-../../.agents/skills/bolder

.claude/skills/clarify

@@ -1 +0,0 @@
-../../.agents/skills/clarify

.claude/skills/colorize

@@ -1 +0,0 @@
-../../.agents/skills/colorize

.claude/skills/critique

@@ -1 +0,0 @@
-../../.agents/skills/critique

.claude/skills/delight

@@ -1 +0,0 @@
-../../.agents/skills/delight

.claude/skills/distill

@@ -1 +0,0 @@
-../../.agents/skills/distill

.claude/skills/extract

@@ -1 +0,0 @@
-../../.agents/skills/extract

.claude/skills/frontend-design

@@ -1 +0,0 @@
-../../.agents/skills/frontend-design

.claude/skills/harden

@@ -1 +0,0 @@
-../../.agents/skills/harden

.claude/skills/normalize

@@ -1 +0,0 @@
-../../.agents/skills/normalize

.claude/skills/onboard

@@ -1 +0,0 @@
-../../.agents/skills/onboard

.claude/skills/optimize

@@ -1 +0,0 @@
-../../.agents/skills/optimize

.claude/skills/overdrive

@@ -1 +0,0 @@
-../../.agents/skills/overdrive

.claude/skills/polish

@@ -1 +0,0 @@
-../../.agents/skills/polish

.claude/skills/quieter

@@ -1 +0,0 @@
-../../.agents/skills/quieter

.claude/skills/teach-impeccable

@@ -1 +0,0 @@
-../../.agents/skills/teach-impeccable

.claude/skills/typeset

@@ -1 +0,0 @@
-../../.agents/skills/typeset

.github/copilot-instructions.md

@@ -1,42 +0,0 @@
-## Design Context
-
-### Users
-The interface serves two primary audiences: evaluation researchers and policymakers. Researchers use it to compare evaluations, understand methodological differences, and inspect evidence quality. Policymakers use it to understand what has been evaluated, how much supporting evidence exists, and which models have broader or thinner reporting coverage.
-
-### Brand Personality
-The product should feel editorial, premium, and vivid. It should communicate credibility and seriousness without becoming visually sterile. The emotional goal is confidence and clarity with a sense of polish, not hype.
-
-### Aesthetic Direction
-The interface should feel like a refined research publication with selective bursts of color. It should work in both light and dark mode. The visual direction should avoid oversized hero metrics, noisy card interiors, and overcrowded dashboards. Information density should be controlled carefully because the homepage presents many cards at once.
-
-### Design Principles
-1. Prefer compact, layered summaries over large isolated stat blocks.
-2. Use color intentionally to create scanability and editorial hierarchy, not decoration.
-3. Support both research and policy reading modes by shifting emphasis rather than duplicating content.
-4. Keep card typography restrained so multiple cards remain legible in a grid.
-5. Make evidence, breadth, and context feel trustworthy and easy to compare at a glance.
-
-### Audience Surface Rules
-
-#### Eval Researcher Mode
-- Lead with methodology, reproducibility, and comparability.
-- Surface inference settings, eval library/version, benchmark setup, generation config, and source relationships prominently.
-- Preserve technical terminology when it helps precise comparison.
-- Prefer tables, filters, exports, score distributions, config diffs, and sample-level inspection.
-- Highlight missing reproducibility fields such as null generation configs as methodological warnings.
-- Make apples-to-apples comparison affordances primary rather than secondary.
-
-#### AI Policy Mode
-- Lead with plain-language interpretation, governance relevance, and source accountability.
-- Translate schema fields into reader-facing meaning rather than exposing raw jargon by default.
-- Surface evaluator independence, reporting organization, test date, benchmark purpose, caveats, and comparability status prominently.
-- Prefer narrative summaries, callouts, badges, and guided explanations over dense technical controls.
-- Make limitations and confidence caveats highly visible to reduce score over-interpretation.
-- Keep technical configuration available, but subordinate it behind clearer public-interest framing.
-
-#### Field Translation Guidance
-- `evaluator_relationship: third_party` should map to an independent verification signal in policy mode.
-- Missing `generation_config` should be treated as a reproducibility gap, not merely an absent field.
-- `retrieved_timestamp` should be surfaced as the date tested because timing matters for governance review.
-- Large size/parameter differences should be surfaced as comparability caveats in policy mode.
-- Instance-level or sample-level data should be a primary exploration tool in researcher mode and a selective illustration tool in policy mode.

.gitignore

@@ -1,60 +0,0 @@
-# See https://help.github.com/articles/ignoring-files/ for more about ignoring files.
-
-*.DS_Store
-
-# dependencies
-/node_modules
-
-# next.js
-/.next/
-/out/
-
-# production
-/build
-/out
-
-# debug
-npm-debug.log*
-yarn-debug.log*
-yarn-error.log*
-.pnpm-debug.log*
-
-# env files
-.env*
-
-# vercel
-.vercel
-
-# typescript
-*.tsbuildinfo
-next-env.d.ts
-.cache/
-pipeline_revised.py
-.local-data/
-
-# Local data dumps. The runtime reads from .cache/hf-data/duckdb parquets;
-# anything under /data/ is leftover from offline scripts and should not
-# ship in git. Survey schema and the curated benchmark categories are
-# loaded statically at build time, so they do ship.
-/data/*
-!/data/survey/
-/data/survey/*
-!/data/survey/eval-schema-fields.json
-!/data/benchmarks/
-/data/benchmarks/*
-!/data/benchmarks/categories.json
-mock_design/
-shoot.mjs
-whisker-render.mjs
-output/
-public/peer-ranks.json
-**/* (1).tsx
-
-# private working notes / design specs / migration plans — not for publishing
-notes/
-docs/INTERPRETIVE_SIGNALS.md
-
-# Playwright e2e output (tests/e2e via @playwright/test)
-test-results/
-playwright-report/
-

README.md

@@ -19,7 +19,7 @@ tags:
 A Next.js application for **viewing** AI evaluations. It is the reader frontend of the
 Eval Cards platform: it does not author or store evaluation data itself — it renders a
 materialised warehouse **view layer** produced upstream by the `eval_card_backend`
-pipeline, and deploys to the Hugging Face Space `evaleval/eval-cards` (Docker runtime).
+pipeline, and deploys to the Hugging Face Space `evaleval/general-eval-card` (Docker runtime).
 
 ## Project Goals
 
@@ -101,8 +101,27 @@ Visit `http://localhost:3000` to verify.
 
 ### Deploy to Hugging Face Spaces
 
-1. Create a new Space at https://huggingface.co/new-space and choose **Docker** as the runtime.
-2. Push this repository to the Space Git (or upload files through the UI). The Space builds the Docker image using the included `Dockerfile` and serves the app on port 3000.
+**GitHub is the source of truth.** This repo lives at
+[`evaleval/eval-cards`](https://github.com/evaleval/eval-cards); the Space
+[`evaleval/general-eval-card`](https://huggingface.co/spaces/evaleval/general-eval-card)
+is a mirror of it. Every push to `main` runs
+[`.github/workflows/sync-to-hf-space.yml`](.github/workflows/sync-to-hf-space.yml), which
+uses [`huggingface/hub-sync`](https://github.com/huggingface/hub-sync) to upload the tree
+to the Space; the Space then rebuilds the Docker image and serves the app on port 3000.
+The workflow can also be run by hand from the Actions tab (`workflow_dispatch`).
+
+Consequences worth knowing:
+
+- **Do not commit directly to the Space.** The sync runs with `delete_removed: true`, so
+  anything on the Hub that is not in the GitHub tree is removed on the next push. Make
+  changes here and let them flow downstream.
+- The sync needs an `HF_TOKEN` repository secret — a Hugging Face token with **write**
+  access to the `evaleval` org.
+- `.github/` and root `.git*` files (including `.gitattributes`) are never uploaded, so
+  the Space keeps its own copy of those.
+- Binary assets under `public/` are tracked with Git LFS, which is why the workflow checks
+  out with `lfs: true`. Without it the Space would receive LFS pointer text instead of the
+  actual images.
 
 Notes:
 - If your build needs native dependencies (e.g. `sharp`), the Docker image may require extra apt packages; update the Dockerfile accordingly.