Skip to content
GRPNR.

04 — Steelman: Adversarial Court Record

Showcase-website architecture decision (plans/005). Each candidate argued by an advocate, attacked by a prosecutor, then one rebuttal each way. Evidence labels ([V]/VERIFIED, [A]/ASSUMPTION) and packet citations preserved as given. No verdict here — the synthesis doc owns the verdict.

Candidate A — Quartz v5 sidecar (vault-publish, do-less lane)

Advocate

Top 3 arguments

1. Only candidate where 81 of 86 pages ship with zero authoring — and the chrome is free. npx quartz create --strategy symlink --source <path> is a VERIFIED-TODAY non-interactive one-liner (pkt-quartz §subset); two symlinks + ignorePatterns/ExplicitPublish (VERIFIED config docs) give exactly the plans/+research/ subset with confidential exclusions enforced in config, not by copy discipline. On first build you get full-text search, backlinks, graph, explorer, TOC, light/dark, and — critically for this corpus — native Mermaid and GFM tables (VERIFIED features page). All 43 mermaid fences render day one. Every rival makes you assemble that chrome from plugins or author it; here time-to-first-value is one command, and the wiki surface is what turns 13.9k lines of program docs into something browsable rather than 5 product pages floating over an unlinked pile.

2. The optimization target is agent page-authoring throughput — and Quartz’s unit of work is the corpus’s own medium. The evidence packet’s agentic-fit verdict is explicit: “content authoring in Quartz is trivially agent-friendly (it’s just Obsidian markdown)” (pkt-quartz §Agentic fit). An agent authoring a new product page writes a markdown file — the exact format of the existing 86 — with no component imports, no routing, no hydration decisions, no config touch. The failure surface of the daily loop is near nil, and what failures exist are legible: static build, no runtime, errors at build time. Contrast the documented silent-failure class in Next (getServerSideProps silently ignored in App Router — pkt-agentic §2) and Astro agents “inventing Next.js patterns inside Astro files” (pkt-agentic §2, caught at build but still tokens burned). No agent-failure reports exist against Quartz (pkt-agentic §2 — a gap, granted, but the daily surface is markdown, where no framework API can be hallucinated).

3. Best exit cost and evolution story of the four — a constitutional requirement. “Exit cost: near zero for content… Quartz clone is a sibling directory you delete” (pkt-quartz §Evolution, VERIFIED architecture: content never moves into the tool; the tool points at the content). Astro/Next/VitePress all pull content into their project structure or wrap it in components/frontmatter conventions; here the plans/ and research/ files remain untouched masters. Evolution is a real ladder: symlinks → theme YAML → Preact components → custom page types, each rung optional (pkt-quartz §Evolution). Deploy-later for Tomas = copy public/ behind CF Access. Main-branch-only, no server, boring — the constitution’s “do-less” lane, literally.

Why it best serves the target

Weight the criteria: throughput (20%) + familiarity/legibility (20%) + time-to-first-value (15%) + corpus fidelity (10%) + simplicity (15%) = 80% of the score sits in lanes where “agents write plain markdown into a pipeline that already renders GFM+mermaid” is the ceiling move. The rivals compete on design ceiling (15%) — but the anti-template rule helps Quartz: what Robert bans is the stock hero/gradient/card-grid landing-page look, i.e., the default output of component-framework agents (pkt-agentic §3: LLMs average to “purple gradients, three-box grids”). Quartz’s editorial/garden register is structurally outside that template, and the packet’s convergent finding is that slop is “a prompting/tokens problem, not a stack problem” (pkt-agentic §3) — the impeccable/frontend-design gates apply equally in every lane, so design ceiling differentiates less than it appears, while the do-less advantages are structural.

Why the risks are manageable

  • v5 post-training-data (the real one). Two containments. Scope: the v4/v5 confusion risk lives only in site customization (pkt-quartz §Agentic fit) — a handful of one-time component builds, not the daily authoring loop the target measures. Mitigation: identical to the loudest documented 2025 agent failure, Tailwind v4, where the fix was “known and cheap: pin syntax rules in CLAUDE.md / use a skill” (pkt-agentic §2); pin the clone, vendor the v5 docs pages (already fetched), and note pkt-agentic §1: Quartz is small TypeScript agents can simply read — the pinned clone is in the context window, which no npm-installed rival framework offers.
  • “Mediocre marketing pages” ceiling (honest ASSUMPTION, pkt-quartz §Customization). The deliverable is an internal showcase for 2 viewers, not a conversion funnel; 5 bespoke Preact page types against a declarative YAML layout with per-page-type overrides (VERIFIED) is a contained, deletable sunk cost — the only one this candidate carries.
  • Project health. 12.8k stars, MIT, active commits through 2026-06 (VERIFIED) — not an abandonment bet; and because content never enters the tool, even abandonment costs a re-render, not a rewrite.

Candidate A is the only option where the site is a view of the repo rather than a second codebase to maintain — and the scoring weights reward exactly that.

Prosecution

Attack 1 — You’re buying the one lane where Quartz is weak, on an API no agent has ever seen

The optimization target is agent speed authoring NEW awesome product pages (20% throughput + 15% design ceiling). Quartz’s own evidence packet concedes both halves:

  • v5 has zero training-data presence — shipped via branch flip in 2026, no tag, post-dating every model’s cutoff; “agents will hallucinate v4 APIs against a v5 checkout unless pinned to docs” (pkt-quartz §Headline, VERIFIED-TODAY branch state; ASSUMPTION-high on hallucination, but this is the exact documented failure class from Tailwind v4 — agents ran dead npx tailwindcss init for a year, pkt-agentic §2, VERIFIED anecdote + official mitigation-skill thread). Except worse: Tailwind v4 had an official agent-skills response and a huge community rule-pack ecosystem; Quartz v5 has a Discord and 33 open issues.
  • The spec’s product pages are “custom Preact components/page types against the new v5 API” — i.e. the entire differentiated deliverable sits on the unfamiliar surface, while the familiar surface (rendering Obsidian markdown) is the part your corpus doesn’t need: ZERO wikilinks, ZERO callouts in 86 files (ground truth). You’d adopt Quartz for superpowers the corpus provably never uses, and pay the novelty tax precisely where throughput is scored.
  • pkt-quartz’s own ceiling call: “excellent knowledge garden, mediocre marketing/landing pages… you’re fighting the tool” (ASSUMPTION, but proponents wrote it). Robert’s anti-template rule bans the wiki-shell look; every Quartz showcase site IS the wiki-shell look (pkt-cases §a, VERIFIED showcase).

Attack 2 — Fork-as-app + mid-transition upstream = the worst ops shape on offer

  • The install model is clone the Quartz repo itself and put your content inside it (pkt-quartz §Build, VERIFIED-TODAY). That’s not a dependency, it’s a fork you now co-maintain. npx quartz update merges upstream into a tree containing your custom Preact page types — on a branch receiving “multiple commits/day clusters” with no tagged release to pin (VERIFIED-TODAY: last tag is v4.0.8, 2023). “Pinned clone of the v5 branch” per spec means pinning an arbitrary commit of an unstable line, then choosing between frozen-forever and merge conflicts through your customizations.
  • Precedent is on the record: v3→v4 was a full rewrite requiring re-migration of all customizations (pkt-cases §a, ASSUMPTION-high, “the canonical Quartz upgrade-pain story”), and v4→v5 just changed the config format and pushed components out to an external plugin registry (pkt-quartz §Customization, VERIFIED-TODAY). Single lead maintainer (pkt-cases, ASSUMPTION). Two rewrites in three majors, one maintainer, no tags — against a constitution that scores simplicity/ops at 15% and prizes “boring wins.”
  • Real adopters’ lived complaints are output-side too: ~4 MiB/page duplicated inline JS, hand-stripping contentIndexScript (which killed search — the headline “free chrome” feature), custom Remark/Rehype patches for links/images/fonts (pkt-cases §a, VERIFIED-TODAY, both adopters patched plugins to stay). The “free” wiki chrome is free until you touch it.

Attack 3 — The “do-less lane” claim is false accounting: near-zero day-1, not near-zero total

Time-to-first-value is genuinely strong (symlink + build --serve, VERIFIED pattern) — but the scoring pays 15% for day 1 and 35% for the months after. Every subsequent unit of differentiated work costs more than the alternatives: custom emitters in an undocumented-to-models API, SCSS in someone else’s factory pattern (QuartzComponentConstructor, props fileData/cfg/tree/allFiles — pkt-quartz, VERIFIED-TODAY), inside a fork. Meanwhile the evidence base for agents doing ANY of this is empty: “no strong agent-experience reports found either way” (pkt-agentic §1, flagged gap). The best-evidenced agent lane for exactly this deliverable — Astro + locked design tokens, 85-page rebuild, ~80% agent-carried (pkt-agentic §1, VERIFIED anecdote) — exists and was measured; Quartz’s agent story is a hope. Choosing the unevidenced option because the first afternoon is cheap inverts the stated optimization target.

Also unpriced: confidentiality by ignorePatterns glob is ASSUMPTION-grade (“low risk” per pkt-quartz) guarding a hard exclusion requirement (research/11+14, monorepo-development) — one glob typo publishes confidential analysis to a port Tomas may later reach; hamatti went manual-build-only for precisely this fear (pkt-cases §a, VERIFIED).

Most likely 6-month regret

Robert asks for the third bespoke product page; the agent burns a session hallucinating v4 APIs into a pinned v5 fork, the diff fights QuartzComponentConstructor and upstream drift, and the page still looks like a wiki wearing a costume. The team then does the obvious thing — hand-rolls standalone pages outside Quartz’s pipeline for anything that must look good — at which point Quartz is reduced to serving 86 files of plain GFM+mermaid that any 50-line static pipeline renders, while its fork, its unpinnable branch, and its stripped-down inline-JS output remain on the maintenance books. Exit is cheap for content (true, VERIFIED) — which is exactly why the retreat happens, and why every hour spent on Preact page types was the sunk cost the spec itself predicted (“custom Preact components are the only sunk cost,” pkt-quartz §Exit).

Cross-examination

Advocate rebuttal

The prosecution’s best point: the differentiated deliverable (5 bespoke pages) sits entirely on the zero-training-data v5 API, while the familiar surface is the one the corpus provably never uses. Three corrections:

  1. The novelty tax is per page type, not per page. The page-type components are built once — with the vendored v5 docs and the pinned clone itself in the context window — and every subsequent product page is markdown + frontmatter selecting that type. The 20% throughput criterion prices the recurring loop, and the recurring loop is markdown.
  2. “No agent has seen v5” understates what a pinned, small-TypeScript clone buys: the agent reads the actual QuartzComponentConstructor source in-window (pkt-agentic §1). Training-data recall is what produced the Tailwind-v4 dead-command loop; ground-truth source in context is its documented cure. And a hallucinated v4 call fails at TypeScript build time — the legible-failure class the constitution rewards — not silently like the App Router props case.
  3. The Astro comparison cuts the other way on totals: its celebrated “85-page, ~80% agent-carried” rebuild had to author all 85 pages. Here 81 need zero. Per-page speed evidence doesn’t beat a candidate that removes the pages from the queue.

Net: one contained, deletable week on an unfamiliar API versus a permanent second codebase — and the exact weighting the prosecution invokes (20/20/15 on loop-shaped criteria) prices the loop, where Quartz’s unit of work is the corpus’s own medium.

Prosecutor rebuttal

The advocate’s best point: 81 of 86 pages ship with zero authoring, the chrome is free, and that covers 80% of the score. Two corrections:

  1. “Zero authoring for 81 pages” is a GFM+mermaid property, not a Quartz property. The corpus is plain GFM plus mermaid with zero wikilinks and zero callouts (ground truth); VitePress, Astro content collections, or a 50-line pipeline renders it the same afternoon. The advocate is banking a criterion all four candidates roughly tie on (time-to-first-value, 15%) to excuse a deficit at the criterion the target actually names — new awesome pages (throughput + ceiling, 35%), the one lane Quartz’s own packet calls “fighting the tool.” The 80% arithmetic also double-counts: familiarity (20%) is precisely where zero-training-data v5 bleeds, and corpus fidelity (10%) is commodity.
  2. “The chrome is free” survives only untouched. The record’s real adopters patched Remark/Rehype plugins for links, images, and fonts, and hand-stripped contentIndexScript to cure 4 MiB pages — disabling search, the headline free feature (pkt-cases §a, VERIFIED). The moment the anti-template rule forces real design work — which is the stated point of the site — the free chrome becomes a fork under a tagless, mid-rewrite upstream. Day-1 cheapness booked as “do-less” is deferred cost, not absence of cost.

Candidate B — Astro 7 + Tailwind v4 bespoke (curated product pages)

Advocate

Argument 1 — It is the only candidate whose evidenced strength IS the optimization target

The target is throughput of newly authored, distinctive product pages, not rendering of existing markdown. The single most detailed agent-experience report in the evidence base is exactly this stack and workflow: an 85→30-page company site rebuilt with Astro + Tailwind + Claude Code, ~80% agent-carried, Lighthouse 95+, with the two success factors named — CLAUDE.md conventions and design tokens locked before coding (pkt-agentic §1, VERIFIED-fetched anecdote). Our spec bakes both in (CLAUDE.md pins + DESIGN.md-locked tokens). The design-ceiling synthesis (pkt-agentic §3, ASSUMPTION flagged) puts custom Tailwind + locked tokens at the top — “nothing fights you” — while VitePress’s default theme is “docs-look floor AND ceiling unless you replace the theme” and Quartz is “mid ceiling, wiki aesthetic by default.” Under Robert’s anti-template rule, the anti-slop mitigation is prompting + token-lock, not stack (pkt-agentic §3 convergent finding), and this is the stack with zero theme to fight while applying it. The impeccable/frontend-design gates compose cleanly with hand-written .astro pages; with Quartz/VitePress they’d first have to claw back control from a theme.

Argument 2 — First-party agentic DX, and every failure mode is loud and pinnable

Astro 7.0 shipped astro dev --background + JSON structured logging explicitly “for AI agent compatibility” (pkt-astro §Agentic DX, VERIFIED-TODAY, first-party blog) — no rival candidate has vendor-built agent affordances in evidence. The known agent failure modes are enumerated and all fail at build time: deprecated @astrojs/tailwind reflex, Sätteri/remark confusion, legacy collections API, and v7’s unclosed-HTML-now-errors change, which the packet itself calls “actually GOOD for agents: fail loud” (pkt-astro §Agentic DX). Contrast the documented Next.js class: getServerSideProps in App Router is silently ignored — empty page, 20-minute debug (pkt-agentic §2, anecdote) — plus caching semantics that churned 15→16 so training data is persistently stale; Vercel’s own MCP answer concedes agents can’t hold Next in their heads. Loud, pre-enumerable failures beat familiar-but-silent ones for failure legibility, and all three Astro pins are one-time CLAUDE.md lines.

Argument 3 — Exact corpus fit with a documented first-class ingestion path, near-zero exit cost

Ground truth: zero wikilinks, zero callouts, 43 mermaid fences, heavy GFM. Quartz’s headline differentiator — native Obsidian wikilinks/transclusions (pkt-agentic §1, VERIFIED) — buys literally nothing here, and its agent-experience evidence is thin (“no strong reports found either way,” pkt-agentic §1). What the corpus does need is covered by pinned, verified pieces: @astrojs/markdown-remark is the official escape hatch restoring the full remark/rehype ecosystem (pkt-astro §pipeline, VERIFIED-TODAY, first-party), astro-mermaid 2.1.0 is active (2026-06-24, VERIFIED), and Content Layer glob({ base: "../plans" }) loads the corpus in place — documented, first-class, no copies or symlinks (pkt-astro §Content, VERIFIED-TODAY). Markdown never moves or converts, so exit cost is discarding “the ~5-file Astro shell” (pkt-astro §Recommended config). Output is fully static dist/ served by python http.server — zero server, matching the simplicity constitution — and CF Access/Tailscale for Tomas later is orthogonal to a static folder.

Why the risks are manageable

  • Sätteri newness: sidestepped entirely — we pin the official, first-party @astrojs/markdown-remark path; nothing in our pipeline depends on a 0.9.x package (pkt-astro §pipeline, VERIFIED).
  • Tailwind v4 training-data lag: the loudest documented failure, but the sources themselves localize it to setup, “not day-to-day utility classes” (pkt-agentic §2, VERIFIED-fetched + official tailwindlabs skills discussion). Setup happens once, via npx astro add tailwind (VERIFIED official path), then it’s frozen in the repo.
  • Astro-4/5-era agent knowledge: the drift points are known and finite (pkt-astro §Agentic DX lists all four); CLAUDE.md pins convert them from failure modes into lint rules.
  • Build/watch at ~100 files: ASSUMPTION-grade (<10s extrapolated from verified thousands-of-files benchmarks; out-of-src file-watching verified on v5, not re-verified on v7) — the honest residual risk, cheap to verify in the first hour and with astro preview/http.server as a trivial fallback loop.

Net

Quartz optimizes for a corpus we don’t have; VitePress and Quartz cap the criterion weighted for design ceiling; Next 16 carries documented silent failures and a hydration runtime a 2-viewer static site never needed. Astro 7 bespoke is the only candidate where the best-evidenced agent workflow, the vendor’s own agent tooling, and the actual corpus requirements all point at the same configuration — every load-bearing piece VERIFIED-TODAY and actively maintained.

Prosecution

Attack 1 — The spec stacks THREE known agent-drift zones, then bets the farm on a CLAUDE.md pin-list

The candidate’s own evidence enumerates its failure modes: agents know Astro “at Astro 4/5 level” and will reach for deprecated @astrojs/tailwind, assume remark/rehype works by default (v7 Sätteri broke that), and emit legacy src/content/ collections (pkt-astro L44-48, ASSUMPTION-high-confidence). Tailwind v4 setup drift is separately “the loudest 2025 failure” — agents run dead npx tailwindcss init, invent configs v4 doesn’t need (pkt-agentic L25, VERIFIED anecdote, corroborated by tailwindlabs #19594). Candidate B is the only lane that takes all three lags simultaneously, and its sole defense is prompt discipline. Pin-lists rot: a fresh cheap Haiku executor (the operating mode is “cheapest capable agents execute”) that skims CLAUDE.md or “helpfully” re-runs astro add reintroduces every one of these. Worse, the Sätteri failure class is silent: drop the @astrojs/markdown-remark pin and mermaid fences render as inert code blocks — no build error, discovered only by eyeball. The evidence packet itself names silent failure “the worst kind for agents” (pkt-agentic L26) — and this spec manufactures a bespoke one.

Attack 2 — Zero field evidence for the exact stack being proposed

Every case study cited in support is a different Astro. Cloudflare docs run Astro 5.13.7 (pkt-cases L18, VERIFIED); Camden’s 7k-page benchmark is v5-era (pkt-cases L19); the flagship “Claude Code rebuilt our site” anecdote is Astro 5 + Tailwind, single unaudited dev.to post (pkt-agentic L8, VERIFIED anecdote). Astro 7.0 is four weeks old; 7.1 is three days old; the Rust compiler, Vite 8 + Rolldown bundler are all new surface the pin can’t avoid (pkt-astro L4-6, VERIFIED). astro dev --background “for AI agents” is marketing-verified, field-unverified — no experience report exists. And the load-bearing content mechanism — glob base: ../plans with dev-server file-watching of out-of-src dirs — is explicitly flagged “worked in v5; not re-verified for v7” (pkt-astro L10, ASSUMPTION). If watching fails for ../ paths, the edit-md→see-change loop degrades to restart-the-dev-server, quietly gutting the #1 weighted target (agent authoring throughput) that this candidate was picked to win.

Attack 3 — The bespoke .astro layer is where the throughput claim actually dies, and Astro gets no credit for the ceiling

The design-ceiling argument leans on DESIGN.md-locked tokens and the installed anti-slop skills — which the evidence says are stack-agnostic (“slop is a prompting problem, not a stack problem”, pkt-agentic L32-35). So Astro’s marginal contribution to the 15% design criterion is ~zero; what it uniquely adds is hand-crafted /products/<x> pages “composing collection entries” — meaning every new product page is a fresh component-composition job where the agent must juggle DESIGN.md + anti-template rule + the v7 pin-list + Content Layer API at once. That’s the slowest authoring unit of any candidate, sitting exactly on the 20% throughput criterion. Meanwhile the ops surface for 86 files / 2 viewers is a full node toolchain: 6+ independently-versioned deps (astro, @astrojs/markdown-remark, astro-mermaid, tailwindcss, @tailwindcss/vite), documented annual major-version churn requiring config touch-ups every cycle (pkt-cases L21, ASSUMPTION-well-documented), and community packages (astro-mermaid 2.1.0) in the critical render path. Fidelity requirement is just GFM + mermaid — the one thing this stack made complicated (pipeline choice is literally “the key decision point”, pkt-astro L12) is the one thing simpler candidates get for free.

Most likely 6-month regret

January 2027: the showcase worked at launch, then sat. Robert returns to add product #6; the executor agent scaffolds against its training-data Astro, the CLAUDE.md pins have drifted from an intervening upgrade (Astro 8 pre-releases, Tailwind minors), pnpm install greets him with peer-dep warnings, and the mermaid/markdown pipeline has silently reverted to Sätteri defaults so diagrams render as code blocks with no error anywhere. He spends the session re-litigating a 2026 framework migration instead of authoring a page — and realizes the curated .astro layer he’s debugging was decoration around markdown that never needed it. The regret isn’t that Astro failed; it’s that he bought a maintenance subscription to the framework-of-the-year for a static rendering of 86 files, payable in exactly the agent-confusion currency the project was scored to minimize.

Cross-examination

Advocate rebuttal

The prosecution’s strongest hit is the manufactured silent failure: drop the Sätteri pin and mermaid fences quietly become code blocks. Two things defang it. First, the failure is trivially convertible to loud, once, mechanically — not by prompt discipline: a 3-line post-build check (astro build && grep -q '<svg' dist/products/*/index.html against a canary fence, wired as the build script) makes any pipeline regression a hard CI/build error forever. The prosecution’s own standard — “all three Astro pins are one-time lines” — applies: this is a fourth one-time line, in package.json rather than CLAUDE.md, immune to pin-list rot because no executor bypasses the build command. Second, the “Haiku re-runs astro add and reintroduces everything” scenario misreads the workflow: setup is frozen in a committed repo with a lockfile on a main-branch-only project; executors author pages, they don’t re-scaffold — and the two loud drift zones (deprecated @astrojs/tailwind, legacy collections) already fail at build time by the prosecution’s own citations (pkt-astro L44-48). What remains is one silent mode, and it’s exactly the one the canary check closes. Note also the “discovered only by eyeball” framing concedes the actual loop: every page here passes through the impeccable/frontend-design gates, i.e. is eyeballed by construction — a diagram rendering as a code block cannot survive the project’s own mandatory review step even without the check.

Prosecutor rebuttal

The advocate’s best card — “the only candidate whose evidenced strength IS the optimization target” — commits an attribution error its own evidence exposes. The flagship case study’s two named success factors are CLAUDE.md conventions and pre-locked design tokens (pkt-agentic §1); the design-ceiling synthesis the advocate cites in the same breath concludes anti-slop is “a prompting problem, not a stack problem” (§3, convergent). Both success factors are stack-portable. So the anecdote evidences the method, and the method transfers to every rival candidate — including ones with a fraction of the surface. What does NOT transfer from that anecdote is precisely what candidate B uniquely adds: it was Astro 5 + old Tailwind, single unaudited dev.to post, n=1, while candidate B ships Astro 7’s four-week-old Rust compiler, Vite 8/Rolldown, the Sätteri pipeline swap, and Tailwind v4 — zero field reports for any of them, by the advocate’s own VERIFIED/ASSUMPTION labels. “Every load-bearing piece VERIFIED-TODAY” verifies existence and maintenance, not agent throughput on this configuration; the one throughput-critical mechanism (glob base: ../plans with live watching) is explicitly not re-verified on v7. The argument thus borrows its evidentiary weight from ingredients every candidate gets for free, and asks the 20% throughput criterion to be scored on an extrapolation.

Candidate C — Next.js 16 static export (house stack)

Advocate

Top 3 arguments

1. The corpus verification collapsed the rivals’ core advantage; what remains is exactly Next’s shape. The md-native lanes (Quartz, VitePress) win on Obsidian fidelity — wikilinks, callouts, transclusions (pkt-agentic §1 [V]). Ground truth: the corpus has zero wikilinks, zero callouts. The real requirement is GFM + 43 mermaid fences — a remark-gfm pass plus one mermaid component, i.e. the ~100-line fs+remark pipeline the evidence packet itself calls “a standard pattern agents write reliably” (pkt-nextvite §a [A]). Once the fidelity moat is gone, the decision is about page authoring, not markdown rendering — and the deliverable is 5+ bespoke product pages, which in every candidate end up as hand-built components anyway.

2. Highest design ceiling on the axis the target actually weights, with the mitigations already installed. The convergent, verified finding: “slop is a prompting/tokens problem, not a stack problem” (pkt-agentic §3 [V], prg.sh + Anthropic cookbook). The known fix — DESIGN.md token-lock + frontend-design/impeccable skill gates — is stack-agnostic, but its execution medium is React/Tailwind, where agent training mass is deepest (“agents have deepest pattern knowledge of Next.js”, pkt-agentic §1). Rivals pay a ceiling tax the packets name explicitly: VitePress polish “lives in Vue SFCs… less training-familiar to agents and off-stack” (pkt-nextvite §b [V]/[A]); Quartz is “mid ceiling, wiki aesthetic by default” with thin agent evidence (pkt-agentic §1, §3 [A]). Next: “per-page React components make ‘awesome product page’ ceilings high” (pkt-nextvite §a [A]). For anti-template pages, unbounded React composition is the ceiling-15% winner — and the throughput-20% winner too, because agents iterate fastest in the idiom they’ve seen most.

3. Only candidate where the constitution’s evolution clause is literally free. “Flip off output: 'export' → full app, zero migration” (pkt-nextvite §a [V-doc]). VitePress: “stays an SSG; app-like needs = migrate” (§b). Quartz/Astro likewise end at static. Exit cost is also bounded and named: “content is markdown + React page shells; moving to any SSG means rewriting shells only” (§a). And this is the house stack — Groupon monorepo and velin are Next, so conventions, rules/ ports, review muscle, and possible velin component sharing all compound instead of forking a second frontend idiom into the program (constitution: training-data familiarity, boring wins — boring for this house is Next).

Why it best serves the optimization target

The target is not “render 86 files” — any candidate does that in a day. It is sustained agent speed on new awesome pages under an anti-template rule. That is a React-composition + skill-gate workload. Choosing Vue (VitePress) or a niche SSG (Quartz) optimizes the solved 10% (corpus fidelity) by taxing the weighted 55% (throughput + familiarity + ceiling) with an off-house idiom on every future page.

Why the risks are manageable

  • Version-drift failures (stale getServerSideProps, caching churn — pkt-agentic §2, anecdote): real, but the identical failure class in Tailwind v4 has a “known and cheap” mitigation — pinned conventions in CLAUDE.md/skills (pkt-agentic §2 [V]). This house already maintains live Next rules (velin rules/); generic-agent drift stats overstate risk for a shop that patrols Next daily. Export mode also shrinks the surface: the unsupported-feature list is documented [V], and misuse fails at next build, not in prod.
  • Weight/build time (300–500 MB, 20–60 s [A]): one-time install + CI-less local builds for 2 viewers on localhost. The 85–250 KB hydration-JS numbers cited against Next are flagged unaudited advocacy figures (pkt-agentic evidence gaps) and are performance-irrelevant at N=2 on loopback.
  • DIY content layer: ~100 owned lines or content-collections (actively maintained, Dub migrated — pkt-nextvite §a [V]). A bounded day-one cost — the only rung of time-to-first-value Next loses — traded for zero ongoing translation between the showcase idiom and the rest of the program.

Prosecution

Attack 1 — It fails the stated optimization target on its own evidence: everything the corpus needs is DIY

The scoring target is agent-authoring throughput (20%) + corpus fidelity GFM+mermaid (10%) + time-to-first-value (15%). Candidate C starts at zero on all three and must build its way up:

  • No content layer at all: @next/mdx is the wrong shape for plans/+research/ outside app/ (R-D3 §a, [V], nextjs.org/docs fetched 2026-07-19). The fix is either a third-party dependency chain with a corpse in it — original Contentlayer dead since ~2023, content-collections is the successor to an abandoned project ([V], R-D3) — or a hand-rolled ~100-line fs+remark pipeline that is [A]-grade, unmeasured, and becomes bespoke code only this repo’s agents have ever seen. That pipeline is precisely the “rebuilding an SSG badly” failure the evidence names for plain HTML (pkt-agentic §1, luminoid).
  • Mermaid — 43 fences in the corpus, the one hard fidelity requirement — is “wiring you own” ([A], R-D3): client component + hydration, or rehype-mermaid + playwright at build. Every competitor gets this as one plugin or native.
  • R-D3’s own fit verdict convicts: Next is right “only if showcase pages will share components with velin or graduate into an app” ([A] judgment). Neither is in the requirements. A 2-viewer localhost showcase is being architected around a hypothetical.

Attack 2 — Documented silent-failure class + persistent training-data staleness, the worst combination for the agents doing the authoring

Agentic familiarity + failure legibility is 20% of the score, and Next.js has the loudest documented agent failure mode of any candidate:

  • Agents emit getServerSideProps into App Router projects and Next silently ignores it — page renders empty, 20-minute debug (pkt-agentic §1, powerdigitalmedia.org anecdote, 2025-10+). Silent failure is the category the packet flags as “worst kind for agents” — contrast Astro, where wrong patterns die at build time (pkt-agentic §2).
  • Static export adds a second silent-ish trap layer: cookies/headers/redirects/ISR/Server Actions/default next/image are all unsupported in export mode ([V], R-D3 §a) — a large, well-trained API surface that agents know well and must not use. Deep training data here is a liability, not an asset: the model’s priors actively fight the export constraint.
  • Caching semantics churned 15→16 (“use cache” rewrite, [V] nextjs.org/blog/next-16), so training data is persistently stale — Vercel’s own remedy is a DevTools MCP, i.e. the vendor concedes agents can’t hold Next in their heads (pkt-agentic §1).

Attack 3 — Maximum ops surface for the minimum site, and the “zero-cost evolution” claim is the trap, not the feature

Simplicity/ops is 15% and the constitution says boring wins:

  • 300–500 MB node_modules and 20–60 s cold builds ([A], R-D3) vs ~100–150 MB / single-digit seconds for the light lane — a heavyweight hydration runtime shipped to exactly 2 viewers on localhost, “pure liability” per pkt-agentic §1 ([A], uncontested).
  • Monthly security-release cadence, next patch due 2026-07-20 ([V], R-D3) — a recurring maintenance appointment for a static site with no server. Every case-study survivor at this scale is a boring md-renders-itself site (Spotify TechDocs lesson, pkt-cases §c, [V]); the documented anti-case is adopting app machinery for a hub (Backstage “overkill below ~50 engineers”, pkt-cases [V]).
  • “Flip off output:'export' → full app, zero migration” is the constitutionally-required evolution story, but it inverts the burden: you pay app-framework costs now, every month, for an app that has no named requirement, no user, and no date. YAGNI is the constitution’s first principle; this is its textbook violation, and the DIY pipeline (Attack 1) is real exit cost in the other direction — bespoke shells no other SSG wants.

Most likely 6-month regret

The showcase never becomes an app — nothing in the decision context says it will — and Robert is left holding a hand-rolled content pipeline + mermaid wiring that only exists in this repo, a monthly Next patch chore, and agents that keep reaching for server-side idioms the export mode silently swallows. Meanwhile new product pages — the actual optimization target — author slower than on a markdown-native stack because every page passes through bespoke React shells and a DIY pipeline instead of “drop .md in folder.” The epitaph writes itself: we chose the house stack for an evolution that never came, and paid app rent on a brochure. (Synthesis of R-D3 fit verdict [A], pkt-agentic §1 contraindication, pkt-cases §c survivor pattern.)

Cross-examination

Advocate rebuttal

The prosecution’s strongest attack (Attack 2 — silent failures + stale priors) convicts the wrong runtime. The staleness it leads with — the 15→16 “use cache” rewrite, the DevTools-MCP concession — lives entirely in the server/data layer that output: 'export' excises: an export site has no runtime cache, no ISR, no Server Actions, so the API surface where Next training data is most stale is exactly the surface this build never executes. Second, its own [V] evidence cuts against it: most of the documented export-unsupported list dies loudly at next build — default next/image loader errors, cookies()/headers() usage fails static rendering with a named route error, Server Actions refuse to compile — which is the Astro-style “dies at build time” legibility the prosecution praises, not the silent class. What genuinely remains silent is one Pages-Router ghost (getServerSideProps ignored in App Router), a single known idiom whose mitigation the packet itself rates “known and cheap”: a pinned convention in CLAUDE.md/skills — in a house that already maintains live Next rules (velin) and reviews Next daily, unlike the generic-agent anecdote’s unpatrolled repo. Finally, at N=2 on localhost every page is eyeballed the minute it builds; a blank page surfaces in seconds on a monitor, not in prod. The residual risk prices out at minutes per incident against a convention file that already exists — not a 20% axis-killer.

Prosecutor rebuttal

The advocate’s best point — “the fidelity moat collapsed, so this is a page-authoring contest, and React’s training mass wins ceiling-15% and throughput-20%” — is dissolved by its own load-bearing citation. The one convergent [V] finding is “slop is a prompting/tokens problem, not a stack problem,” and the named fix (DESIGN.md token-lock + skill gates) is explicitly stack-agnostic. If the ceiling is set by prompting and gates, ceilings converge across candidates, and React’s training mass buys little on the 15% — the differentiators shift back to the costs that do NOT converge: DIY content pipeline, hand-wired mermaid, 300–500 MB weight, monthly patch cadence, all uniquely Next’s. The throughput claim is equally unmeasured: no packet contains a single timed comparison of agents authoring a bespoke page in React vs Vue/Astro — it is inference from training-mass priors, [A]-grade at best, while the only quantified figures the advocate leans on elsewhere are the very ones flagged as unaudited advocacy. And “bespoke components anyway” hides an asymmetry: five page shells are a bounded one-time cost in every stack, but only Next adds a permanent bespoke substrate — the ~100-line fs+remark pipeline — with zero training data behind it, inverting the exact familiarity principle being invoked. “Boring for this house is Next” conflates the app monorepo with a doc hub; the [V] survivor pattern (Spotify TechDocs) says hubs endure as md-renders-itself, house stack or not.

Candidate D — VitePress 1.6.4 custom theme (markdown-native lane)

Advocate

Top 3 arguments

1. It is the only candidate where the corpus requirement is met with zero glue code. Ground truth: the corpus is 86 files of GFM tables + 43 mermaid fences, zero wikilinks, zero callouts. VitePress ships exactly that natively: GitHub-flavored alerts built in [V, R-D3 §b markdown pipeline], mermaid via vitepress-plugin-mermaid — maintained, documented, one config block [V, R-D3], and md-outside-src is native (“drop .md in folder → page”) [V/A, R-D3 comparison table]. Every rival pays an assembly tax for this: Next.js needs content-collections or ~100 hand-rolled LOC plus DIY mermaid [V/A, R-D3 §a]; Astro needs content-collection wiring and its own mermaid integration; Quartz’s headline edge — native wikilinks/transclusions [V, R-E1 §1] — is worth nothing against a corpus with zero of either. VitePress banks 100% of the fidelity requirement on day one; nobody else does it for free.

2. Highest agent-authoring throughput with the most legible failure modes. The optimization target is speed at which agents author new pages. VitePress’s authoring loop is: write markdown, page exists — no route file, no page shell, no frontmatter schema. Config is one small TS file with massive 1.x training-data presence [A, R-D3 §b agentic fit]. Contrast the documented failure classes elsewhere: Next.js agents emit getServerSideProps into App Router and the page silently renders empty — the worst failure class for agents [V-anecdote, R-E1 §2] — with caching semantics that churned 15→16 so training data is persistently stale [V, R-E1 §1]; even Vercel’s mitigation (an MCP) concedes agents can’t hold Next in their heads. Astro’s failures are at least caught at build time [R-E1 §2] — but Astro’s best-evidenced lane pairs with Tailwind v4, whose setup is the loudest documented agent failure of 2025 [V-anecdote, R-E1 §2] (mitigable, but it’s a tax VitePress doesn’t charge). Quartz has no agent-experience evidence either way [R-E1 §1, thin-evidence flag] and a small enough corpus that agents must read its source. VitePress fails loudly (Vite build errors, no hydration runtime) and has years of 1.x in training data.

3. The design-ceiling objection dies against the actual spec: custom theme, not default theme. R-E1’s honest knock — “VitePress default theme = docs-look floor AND ceiling unless you replace the theme” [A, R-E1 §3] — is conditional, and candidate D is built on the condition: own Layout.vue kills the docs chrome entirely, layout: page frontmatter gives a blank canvas per product page, Vue components inline in any markdown file — all first-class, documented [V, R-D3 §b theme customization]. Meanwhile the convergent finding is that slop is a prompting problem, not a stack problem [V, R-E1 §3] — the anti-template mitigations (DESIGN.md token-lock, named direction, frontend-design/impeccable gates already installed) are stack-agnostic. On a blank canvas with locked tokens, VitePress’s ceiling is “whatever CSS you write,” same as Astro’s — but reached after seconds-long builds [A, R-D3] instead of a pipeline you first had to assemble.

Why it best serves the optimization target

The target is throughput on new awesome pages, weighted alongside familiarity, simplicity, and time-to-first-value. VitePress converts the entire existing corpus to a navigable site (sidebar, nav, search free) on day one — time-to-first-value measured in an hour, not a sprint. Then each new product page is one markdown file plus optional scoped Vue for polish. ~100–150 MB, single-digit-second builds [A, R-D3] vs Next’s 300–500 MB, 20–60 s, and monthly security-patch cadence on a site with no server [V/A, R-D3 §a] — the smallest ops surface of any framework candidate, on a main-branch-only internal repo where boring wins. R-D3’s own synthesis: “VitePress wins the stated optimization target” [A, R-D3 net].

Why the risks are manageable

  • Vue is off-stack (house is React). Real, but scoped: agents author markdown, and Vue only appears in the theme layer — a handful of SFCs, written once, touched rarely. Vue SFC training data is abundant even if thinner than React. Exit cost is named and small: the markdown is portable as-is; only theme components are a rewrite [A, R-D3 §b exit] — the content, which is the asset, never gets locked in.
  • 2.0 is alpha. Pin 1.6.4 (stable, npm latest) [V, R-D3 §b version]; no forced upgrade, no monthly patch treadmill.
  • Plugin rot. No 2025–26 VitePress plugin-breakage reports found under agents [R-E1 §2 — gap, not absence]; the one plugin we depend on (mermaid) is maintained [V], and the fallback is markdown-it config we own.
  • “Astro has better agent evidence.” True and conceded [V-anecdote, R-E1 §1] — but that evidence is a Tailwind marketing-site rebuild, not a markdown-corpus showcase. For this corpus shape, VitePress reaches the same anti-slop ceiling through the same skill gates, with strictly less assembly between now and the first awesome page.

Prosecution

Attack 1 — The spec buys VitePress for features the corpus doesn’t use, then deletes the rest

VitePress’s verified edges are callouts near-native, wikilinks-via-plugin, and free docs chrome (pkt-nextvite (b), [V]). Ground truth: the corpus has zero wikilinks and zero callouts — the real requirement is GFM tables + mermaid, which every candidate meets (mermaid is one plugin/config block on any stack). The remaining edge — default theme’s free sidebar/nav/search/dark-mode, the substance of “minutes not hours” (pkt-nextvite (b) fit verdict, [A]) — the spec discards on day one: “own Layout.vue kills docs chrome.” A custom theme starts from a blank Layout (pkt-nextvite (b), [V] via vitepress.dev/guide/custom-theme); nav, search wiring, theming, prev/next get rebuilt by hand against default-theme internals that VitePress documents thinly and that the 2.0 alpha is actively churning (2.0.0-alpha.18, pkt-nextvite (b) [V] — so the 1.6.4 pin is a branch with a port already owed). What’s left after the deletion is a markdown-it config — not a moat, and not worth the Vue tax below.

Attack 2 — Off-stack Vue guts the two top-weighted criteria, in the least-evidenced quadrant

The optimization target is agents authoring NEW awesome product pages. The spec’s own evidence concedes: “polish lives in Vue SFCs, not React” and “custom Vue themes are less training-familiar to agents than React, and off-stack for this house” (pkt-nextvite (b), [A]). pkt-agentic §2 found no agent-experience reports for VitePress at all (“gap in evidence”), and its §3 ceiling synthesis rates VitePress “docs-look floor AND ceiling unless you replace the theme” — Candidate D’s answer is “replace the theme,” which relocates the whole bet into the quadrant with zero evidence: agents writing distinctive custom Vue. Meanwhile the installed anti-slop gates (impeccable, frontend-design, design-taste-frontend) and all house muscle memory (monorepo + velin = Next/React) are React/Tailwind-idiom. Every awesome page is an agent writing Vue with weaker priors, reviewed by a human who doesn’t write Vue — failure legibility (20% weight) degrades precisely where the anti-template rule needs it sharpest. [A — but built on the packet’s own admissions; proponents cannot call this unfair.]

Attack 3 — The corpus itself can break the build, illegibly; the confidential-exclusion design is fail-open or self-contradicting

VitePress compiles every md page as a Vue template: bare {{ … }} and unclosed pseudo-tags (<repo>, <id>) outside code fences — exactly the tokens that appear in heavy GFM tables of an infra-refactor corpus (86 files, ~13.9k lines) — throw compile errors (“Element is missing end tag”) that point at generated SFC output, not the source md line. [A — well-known VitePress failure class, not covered in the packets; the packets’ silence on it is itself the gap.] Second, VitePress hard-fails builds on dead links by default: relative links into the excluded confidential dirs (analysis/monorepo-development/, research/11+14) force ignoreDeadLinks: true, converting a safety rail into silently broken nav. Third, “content via symlinked src dirs” forks badly either way: dir-level symlink + srcExclude is fail-open on confidential files (one glob typo publishes research/11); per-file symlinks are fail-closed but kill the “drop md in folder → page” claim — new files don’t appear until someone re-links. Either branch contradicts a headline spec claim. [A]

Most likely 6-month regret

The showcase is the only Vue codebase in an all-React house. Agents’ Vue product pages keep bouncing off the anti-template gate (thin Vue design priors, no house reviewer who smells bad Vue), so “new awesome page” throughput — the 20% headline criterion — lands slower than the markdown-lane pitch promised. Robert is now maintaining a bespoke theme welded to 1.x internals with the 2.0 port unpaid, and the exit is priced in the packet itself: “custom Vue theme components are a rewrite” (pkt-nextvite (b), [A]) — whereas the corpus, being plain GFM+mermaid, would have ported to Astro or Next in an afternoon. The regret isn’t that VitePress fails; it’s that everything paid for it (Vue tax, custom theme, version pin) purchased advantages this corpus, verifiably, never needed.

Cross-examination

Advocate rebuttal

Target: Attack 2 — “off-stack Vue guts the two top-weighted criteria in the zero-evidence quadrant.” The attack conflates “custom Vue theme” with “agents writing distinctive Vue.” What makes a page distinctive is layout, type, spacing, color — CSS — and a static showcase SFC is <template> (HTML) + <style scoped> (CSS) with near-zero framework logic: no state, no hydration, no composables. The “thin Vue priors” concern applies to Vue application code, which candidate D barely contains; the priors that matter here are HTML/CSS priors, which are stack-invariant. Second, “no agent-experience reports” (pkt-agentic §2) is a gap, not negative evidence — and the same gap indicts Quartz while Astro’s positive evidence is one Tailwind marketing rebuild [V-anecdote, R-E1 §1]; meanwhile VitePress itself is the docs engine of Vue, Vite, Vitest, Rollup, Pinia — its config and theme API are saturated in training data even where reports are absent. Third, failure legibility does not degrade where claimed: static SFCs fail at Vite build time with file/line, and there is no client runtime to render silently wrong — the reviewer who “doesn’t write Vue” reviews the rendered page, and the installed gates (impeccable, frontend-design) judge output, not framework idiom; you don’t need to smell bad Vue to smell a templated design. Finally, scope: the Vue surface is a handful of theme SFCs written once; each new product page is markdown plus optional scoped style. The bet is not relocated into the zero-evidence quadrant — it mostly never leaves the markdown-plus-CSS quadrant, where evidence is abundant.

Prosecutor rebuttal

Target: Argument 2 — “highest agent-authoring throughput with the most legible failure modes.” Both halves overreach. The throughput half measures the wrong loop: “write markdown, page exists” describes commodity pages every candidate ships. The graded criterion is new awesome-looking pages under an anti-template rule — and a bespoke theme renders every markdown file into the same one look, so each page that must look different needs new Vue layout/components, exactly the work the loop claim excludes. Worse, once Layout.vue kills the docs chrome, “page exists” no longer means “page is reachable”: sidebar/nav in a custom theme are hand-wired config — the route file returns wearing a different hat. The legibility half is empirically wrong on this corpus: VitePress compiles md as Vue templates, and a fence-aware scan of the actual repo (2026-07-19) finds 14 bare pseudo-tags outside code spans in 3 files — <canonicalTaskId>, <slug>, <internal-plane-app-root> in plans/003-atlas-intelligence-layer/07-ux-ui.md, plans/002-dual-run-parity-harness/ux-ui.md, plans/002-work-ledger-product/10-architecture.md — each a day-one “Element is missing end tag” error pointing at generated SFC output, not the source line. Small count, but infra-writing agents emit <placeholder> tokens habitually, so this is a recurring lint tax on the exact loop being sold as frictionless — “fails loudly” is true, “fails legibly” is not. The Next.js contrast is real but beside the point: the live rival is Astro, whose failures the advocate concedes are build-time-caught with positive agent evidence, and whose “Tailwind tax” is optional, not structural.