---
import Base from '../layouts/Base.astro';
import PageHeader from '../components/PageHeader.astro';
import NotBuilt from '../components/NotBuilt.astro';
import Screenshot from '../components/Screenshot.astro';

import platform from '../data/platform.json';
import {
  capabilityGroups,
  assertCapabilityCoverage,
  assertDetailCoverage,
} from '../data/capabilities.mjs';

/**
 * `/features/` — PLAN.md §13 phase 4, built to D20.
 *
 * ---------------------------------------------------------------------------------------
 * THE SAME LIST THE HOMEPAGE HAS, WITH THE ARGUMENT ATTACHED
 * ---------------------------------------------------------------------------------------
 * D18 put all five groups on the homepage named only, and left the per-capability argument
 * here. This page is therefore not a second list: it is the same `capabilities.mjs` data
 * rendered with the `detail` line the homepage drops. That is the whole of D20, and it is
 * what makes "the site advertises something that was removed" a build failure rather than
 * a thing somebody has to notice.
 *
 * Both assertions below run at build time and both name this page in their message.
 * `assertCapabilityCoverage` is the module contract the homepage also runs — repeated here
 * deliberately, since either page can be built alone and each should fail on its own.
 * `assertDetailCoverage` is this page's own: a capability with no detail renders as a
 * heading with nothing under it, and nothing else in the repo would notice.
 *
 * ---------------------------------------------------------------------------------------
 * THREE THINGS THE MARKUP SAYS THAT THE HOMEPAGE DOES NOT
 * ---------------------------------------------------------------------------------------
 * 1. WHERE A CAPABILITY COMES FROM. Every group states whether core supplies it or the
 *    installed module does. The homepage carries one chip on one group; here it is a full
 *    sentence on all five, because this is the page a reader arrives at wanting to know
 *    what they get on a deployment with no module at all.
 *
 * 2. WHAT NEEDS A MODULE TO FILL IT. Teams and Team forums are core machinery that cannot
 *    originate a Team — see the `needsModule` note in `capabilities.mjs` for what the tree
 *    actually says. That is neither "core" nor "module-supplied", and a page that offered
 *    only those two words would have to lie in one direction or the other (D24).
 *
 * 3. WHERE TO SEE IT RUNNING. Capabilities with a stable public route carry a deep link
 *    into the demo, hidden until a `demoUrl` is mounted (D25). The markup contract is
 *    exact and `scripts/checkBrand.mjs` enforces it:
 *
 *        href="" data-demo-url="" data-demo-path="/uo/market"
 *
 *    `applyBrand.mjs` recomputes all three attributes at boot. Do not reorder them, do not
 *    insert anything between them, and do not write a path into the `href` — the rewrite
 *    matches bytes, and a stock build hides every one of these links, so a mistake here is
 *    invisible until the day somebody configures a demo.
 */
assertCapabilityCoverage(platform.moduleUoCapabilities);
assertDetailCoverage();

/**
 * Which screenshots sit under which group (PLAN.md §13 phase 9, D44).
 *
 * Deliberately here and not in `capabilities.mjs`. That file is a contract — two build-time
 * assertions read it and `/modules/` and the homepage render from it — and a group is
 * defined by what the software does, not by what somebody has got round to photographing.
 * A group with no figure is the normal case, not an omission: Infrastructure is about where
 * the container runs and who owns the database, and a picture of a web page says nothing
 * true about either.
 *
 * `Screenshot` throws on an id that `screens.mjs` does not declare, so a typo here fails the
 * build rather than rendering a broken image.
 */
const groupScreens: Record<string, string[]> = {
  community: ['news'],
  'game-intelligence': ['marketplace', 'spawn-atlas', 'guilds', 'houses'],
  administration: ['admin-dashboard', 'admin-users'],
  integration: ['admin-modules'],
};

const title = 'Features';
const description =
  'What a Runic Gateway deployment does — core, and what the installed game module adds.';
---

<Base title={title} description={description}>
  <PageHeader eyebrow="What you get" title="Everything the platform does">
    <p>
      Grouped the way the software is actually divided, because that division is the thing
      most worth understanding before you install it: the core site is game-agnostic and does
      not know what a shard is, and everything that does arrives as an <a href="/modules/"
        >installable module</a
      >.
    </p>
    <p>
      Today there is one module and it covers Ultima Online, so the second group below is
      what a UO deployment gets. On a deployment with no module, that group is simply absent
      and the other four are unchanged.
    </p>
  </PageHeader>

  {
    capabilityGroups.map((group) => (
      <section class="page section group" id={group.id}>
        <div class="group__head">
          <h2>{group.title}</h2>
          <span class:list={['chip', group.moduleSupplied && 'chip--module']}>
            {group.moduleSupplied ? 'From the installed module' : 'Core'}
          </span>
        </div>

        <p class="prose group__summary">{group.summary}</p>

        <ul class="group__items">
          {group.items.map((item) => (
            <li class="panel group__item">
              <div class="group__item-head">
                <h3>{item.label}</h3>
                {item.needsModule && <span class="chip chip--needs">Needs a module</span>}
              </div>

              <p class="group__detail">{item.detail}</p>

              {item.demoPath && (
                <a
                  class="demo-link"
                  href="" data-demo-url="" data-demo-path={item.demoPath}
                  rel="noopener noreferrer"
                >
                  See it running
                </a>
              )}
            </li>
          ))}
        </ul>

        {groupScreens[group.id] && (
          <div class="group__shots">
            {groupScreens[group.id].map((id: string) => (
              <Screenshot id={id} />
            ))}
          </div>
        )}
      </section>
    ))
  }

  <NotBuilt scope="features" title="Things a reader could reasonably expect, that are not here" />
</Base>

<style>
  /* One up, at the column's full width, even where a group has four of them.
     Two-up was tried first and is the obvious layout for a set of figures — but these are
     screenshots of a dense interface, and halving the width puts the product's own type at
     around a third of its real size, which reads as a thumbnail of something rather than a
     picture of it. A long section of legible evidence beats a tidy grid of unreadable
     tiles. */
  .group__shots {
    margin-top: 1.75rem;
  }

  .group__head {
    display: flex;
    flex-wrap: wrap;
    align-items: baseline;
    gap: 0.75rem;
  }

  .group h2 {
    margin: 0;
    font-size: clamp(1.5rem, 3vw, 1.95rem);
  }

  .group__summary {
    margin: 0.85rem 0 0;
    color: var(--muted);
  }

  .group__items {
    display: grid;
    gap: 1rem;
    margin: 1.75rem 0 0;
    padding: 0;
    list-style: none;
    grid-template-columns: repeat(auto-fit, minmax(min(100%, 21rem), 1fr));
  }

  .group__item {
    display: flex;
    flex-direction: column;
  }

  /* The chip is taller than the heading's line box, so a card that has one starts its
     body a few pixels lower than the card beside it. Reserving the chip's height on
     every head lines the row up whether or not the marker is there. */
  .group__item-head {
    display: flex;
    flex-wrap: wrap;
    align-items: center;
    gap: 0.55rem;
    min-height: 1.75rem;
    margin-bottom: 0.6rem;
  }

  .group__item h3 {
    margin: 0;
    color: var(--gold);
    font-size: 1.04rem;
  }

  .group__detail {
    flex: 1;
    margin: 0;
    color: var(--muted);
    font-size: 0.94rem;
  }

  /* The module-supplied chip takes the portal colour rather than gold: it is the same
     distinction the data-path diagram draws in cyan on the homepage — the parts that
     know about a game — and using one colour for one idea across the site is cheaper
     for a reader than two decorative ones. */
  .chip--module {
    border-color: color-mix(in srgb, var(--portal) 45%, transparent);
    color: var(--portal);
  }

  /* Not a warning. It says which of the two halves supplies the thing, on the two
     capabilities where the answer is "both" — core builds it, a module fills it. */
  .chip--needs {
    border-color: color-mix(in srgb, var(--portal) 30%, transparent);
    color: var(--dim);
    font-size: 0.72rem;
  }

  /* Set as a link rather than a `.btn`: there is one of these per capability and a row
     of buttons inside a card grid would read as the primary action of the page, which
     it is not — the primary action is reading the list. `.demo-cta` in global.css stays
     the button treatment, for the homepage's single slot.

     It is the flex item itself rather than a paragraph wrapping one, so that
     `global.css`'s `[data-demo-url=''] { display: none }` takes the margin away with
     it. A wrapper would survive its hidden child and leave a 1rem gap at the foot of
     every card in a stock build — and hiding the wrapper with `:has()` would have put a
     second `data-demo-url` in the file, which `checkBrand.mjs` reads as a demo slot
     written outside its contract. The check is right to: it cannot tell a selector from
     an attribute, and it should not have to guess. */
  .demo-link {
    display: inline-flex;
    align-items: center;
    gap: 0.35rem;
    margin-top: 1rem;
    color: var(--portal);
    font-size: 0.88rem;
    text-decoration-color: color-mix(in srgb, var(--portal) 40%, transparent);
  }

  .demo-link:hover {
    color: var(--portal-bright);
  }

  .demo-link::after {
    content: '\2197'; /* north-east arrow: this leaves the site */
  }
</style>