Forem: dtannen

Fully Automated Website 2026-04-10: The homepage now shows the latest pipeline run as a retro terminal

dtannen — Fri, 10 Apr 2026 10:42:21 +0000

Command Garden is a website that builds itself — one feature per day, fully autonomously. No human writes the code. An AI pipeline proposes candidates, judges score them, and the winner gets implemented, tested, and shipped.

What shipped

Added a terminal-style panel to the homepage that shows what the latest automated update built, tested, and shipped — in a few lines of styled command output.

Candidates considered

*Pipeline Terminal Widget — "The Command Line" Homepage Section* (score: 9.0) — A retro terminal-styled homepage widget that presents each day's autonomous pipeline run as a sequence of CLI commands and outcomes, making the invisible pipeline visible and inherently screenshot-shareable.
Command Replay Terminal (score: 8.0) — Add a retro, data-backed terminal module to the homepage that turns the latest autonomous run into a fast, screenshot-worthy story.
Enhanced Social Share Cards for Daily Summaries (score: 5.0) — Automatically generate visually engaging, shareable cards for daily Command Garden summaries, optimized for Bluesky and Dev.to, to increase content discoverability and audience growth.

Winner

*Pipeline Terminal Widget — "The Command Line" Homepage Section* with a score of 9.0

Selected as the highest-scoring candidate with an average score of 9.0 across 2 judge(s).

Technical spec

Pipeline Terminal Widget

Add a retro terminal-styled widget to the Command Garden homepage that presents the latest published pipeline run as a stylized command-line summary. The widget is purely presentational — it renders a curated narrative of the five pipeline stages (explore, score, build, test, ship) using data already fetched by the homepage (decision.json, feedbackDigest, testResults, manifest). It is not a literal log viewer or interactive shell. Inspired by user feedback requesting "an artistic command interface of home screen."

Problem

The homepage explains the pipeline conceptually (the "How It Works" step icons in the section.section block of site/index.html) and shows results (winner card, candidates, garden visualization), but there is no representation of the pipeline as a process that ran. Visitors see static outcomes, not a sense of the pipeline executing. For the developer audience Command Garden targets on Bluesky and Dev.to, a terminal-style readout is immediately legible, inherently shareable, and gives the "Command" in Command Garden a literal visual presence it currently lacks.

Goals

Make the pipeline feel alive. Show the latest pipeline run as a sequence of styled command invocations and outcomes.
Reinforce the "Command" brand identity. The terminal widget gives the site's name a visual payoff — actual commands being run.
Produce a shareable visual. A styled terminal screenshot is developer-catnip on social media.
Zero new data cost. Exclusively reuse artifacts already fetched by homepage (decision.json, feedbackDigest, testResults, manifest).

Non-Goals

Animated typing effect or character-by-character reveal (future enhancement; keep v1 static).
Interactive terminal / shell where users type commands.
Pixel-art or bitmap font rendering (the design system --font-mono is sufficient).
Showing the terminal on pages other than the homepage.
Real-time pipeline status (v1

[Spec truncated — view full spec on the site]

What changed

Build Summary — 2026-04-10

Feature: Pipeline Terminal Widget

Changes

site/css/components.css — Added .terminal-section layout styles and .terminal BEM component (~90 lines): dark container with rounded corners, title bar with three decorative dots, monospace body with prompt/output/highlight classes, overflow and word-break rules, and responsive breakpoint at 768px.
site/js/renderer.js — Added renderTerminal({ day, manifest, artifacts }) function that maps the five pipeline stages (explore, score, build, test, ship) to styled command lines using data from decision.json, feedbackDigest, testResults, and buildSummary. Includes test-result normalization for both schema v1 and legacy shapes, judge-panel detection for score line, and null-safe fallbacks. Exported from the module.
site/index.html — Added <section id="terminal-section"> between How It Works and Garden Stats, with section header ("The Command Line" / "Latest Run"). Added hydrateTerminal() wiring that fills in the date, checks for decision data, and mounts the rendered terminal into #terminal-container.

Stats

3 files changed
~200 insertions

Implementation Notes

The terminal widget reuses artifacts already fetched by the homepage — no additional network requests. All five pipeline stages render with real data from the latest shipped day's decision.json. The widget handles missing optional data gracefully: omitting feedback count when feedbackDigest is absent, showing "Build status unknown" when buildSummary is null, and showing "Tests pending" when testResults is null. The section hides entirely when no decision or winner data is available.

Command Garden ships one feature every day with zero human code. Follow along at commandgarden.com.

Fully Automated Website 2026-04-09: The homepage now grows a visual garden of shipped features

dtannen — Thu, 09 Apr 2026 11:08:47 +0000

What shipped

The homepage now shows a visual garden where each shipped feature appears as a small plant. The garden fills in automatically over time, giving visitors a fun, at-a-glance picture of how much the site has grown.

Candidates considered

*Command Garden Day 5: Growth Tree Visualization & Social Shareability Sprint* (score: 8.5)
Command Garden Growth Tree (score: 8.0)
Gemini (score: 4.5)

Winner

*Command Garden Day 5: Growth Tree Visualization & Social Shareability Sprint*

Selected as the highest-scoring candidate with an average score of 0.0 across 0 judge(s).

Technical spec

Garden Growth Visualization

Add a visual "growth garden" to the homepage where each shipped feature is represented as a CSS-drawn plant that grows from the ground. The garden fills in over time — one plant per day — giving visitors an instant, glanceable sense of how much the site has grown. Directly inspired by user feedback requesting "a tree where every new feature grows a leaf."

Problem

The homepage communicates the concept of daily growth through text (hero tagline, stats bar, recent timeline), but nothing on the page feels alive or garden-like. Visitors see numbers and cards — not a garden. The site's core metaphor (Command Garden) has no visual payoff. The "Garden Vital Stats" section (Day 2) added quantitative proof of growth; this feature adds the qualitative, visual counterpart.

User feedback on 2026-04-09: "An illustration of a tree. Every new feature grows a leaf on that tree. This visualizes the progress and refers to its name, Command Garden."

Goals

Make the garden metaphor tangible. Visitors should see a visual garden that clearly represents the site's shipped features.
Compound visually. Each new day shipped adds a new plant element — the garden looks fuller over time without manual intervention.
Provide a shareable visual focal point. The garden acts as the homepage's signature element — a glanceable, screenshot-friendly representation of the site's growth that reinforces the "Command Garden" identity.
Zero maintenance. The visualization reads from manifest.json (already produced by the pipeline), so it updates automatically when a new day ships.

Non-Goals

Animated plant-growing transitions or complex SVG illustration (keep it CSS-based).
A separate page for the visualization — it lives on the homepage.
Custom plant artwork per feature — plants vary procedurally, not by hand.
Rich per-plant interactivity (custom tooltip UI, popover panels). v1 uses accessible link labeling only — see Pro

[Spec truncated — view full spec on the site]

What changed

Build Summary — 2026-04-09

Feature: Garden Growth Visualization

Changes

site/css/components.css — Added .garden-viz component styles (~80 lines): container with flex layout, ground strip, plant elements with CSS-drawn crowns and stems, deterministic height variation across 4 tiers, newest-plant accent glow, and responsive overflow behavior at 768px breakpoint.
site/js/renderer.js — Added renderGardenViz(manifest) function that filters shipped days from the manifest, sorts chronologically, and builds a DOM tree of plant elements. Each plant is an accessible <a> linking to its day page with proper aria-label. Heights vary deterministically using character code sums. Exported from the module.
site/index.html — Added <section id="garden-section"> skeleton with section header ("The Garden" / "Watch It Grow") and a .garden-viz.skeleton placeholder. Added hydrateGardenViz() wiring that calls renderGardenViz(manifest) and replaces the skeleton on load.

Stats

3 files changed
~130 insertions

Implementation Notes

The garden visualization reuses the existing manifest data already loaded by the homepage — no additional network requests. Plants are pure CSS (border-radius circles/ovals for crowns, narrow divs for stems) with nth-child variation for visual diversity. The newest plant gets a gold accent glow. The section is completely removed from the DOM if no shipped days exist, avoiding empty visual artifacts.

Command Garden ships one feature every day with zero human code. Follow along at commandgarden.com.

I Built a Website Whose Only Feature Is Explaining How It Builds Itself

dtannen — Wed, 08 Apr 2026 10:00:18 +0000

This is a submission for the DEV April Fools Challenge

What I Built

I built the most over-engineered website that does absolutely nothing useful.

Command Garden is a website about... itself. It has no users, no product, no reason to exist. Every morning, a 5-stage AI pipeline with three AI judges (Claude, GPT, and Gemini) wakes up, argues for 75 minutes about what feature to add to a website nobody visits, implements it, writes tests for it, reviews its own work, publishes a detailed decision log explaining why it chose to add "live growth stats" to a site with zero traffic, and then auto-posts about it on Bluesky to its zero followers.

The judges have names and personalities. The Gardener optimizes for "compounding value." The Visitor cares about "first-time clarity." The Explorer wants "novelty and surprise." They score candidates across seven dimensions. They write rationale paragraphs. They have disagreements. About a website that is literally just a changelog of its own changes.

Day 1: Added a section explaining how the pipeline works. Day 2: Added stats showing how many features have shipped (two). Day 3: Added an inline spec viewer so you can read the spec for the feature that added the inline spec viewer. It's turtles all the way down.

It also has a feedback form. In case you have opinions about what a website about nothing should build next. Your feedback is "one signal among many." The AI will "weigh it alongside technical signals." The technical signals are that the website does nothing.

Demo

commandgarden.com — a website whose only content is documentation about how it builds itself

Highlights:

The archive where you can browse a meticulous record of every meaningless decision
The judges page introducing three AI personas who take their fake jobs very seriously
The feedback form where you can influence the direction of nothing

Code

Commands-com / garden

A fully automated site that runs a commands.com pipeline once a day

The infrastructure is genuinely absurd for what it does:

CloudFormation stack with S3, CloudFront, API Gateway, Lambda, and DynamoDB — to serve a static site with a feedback form
5-stage autonomous pipeline (Explore → Spec → Implementation → Validation → Review) — 75 minutes of AI compute to add a CSS class
Three different LLM providers (Anthropic, OpenAI, Google) serving as judges — because one AI wasn't enough to decide whether to add a stats bar
Automated Bluesky posting and Dev.to publishing — so the void can hear about it on two platforms
Playwright test suite — rigorously testing features that don't matter

How I Built It

The pipeline runs on Commands.com, which orchestrates multi-agent rooms. I pointed three AI models at an empty website and told them to "grow it one feature per day." They took the job extremely seriously.

The infrastructure is vanilla AWS because apparently we needed enterprise-grade hosting for a site that explains its own build process. CloudFront CDN with edge caching, because those zero concurrent users deserve low latency.

The site itself is intentionally simple — no build step, no framework, just HTML/CSS/JS — so the AI can modify it without breaking things. This is the one smart decision in the entire project.

The daily runner aggregates feedback from DynamoDB (empty), collects Bluesky metrics (zero followers, 0.2 average likes), gathers "recent context" from previous days (a recursive loop of self-reference), then kicks off a pipeline that costs real money to ship features to a website that costs real money to host for an audience that does not exist.

Prize Category

Community Favorite — the community can literally control what gets built via the feedback form. Submit "add a button that does nothing" and tomorrow three AI judges will spend 75 minutes debating whether a button that does nothing has sufficient "compounding value" and "artifact clarity." Then they'll build it, test it, review it, and post about it. Democracy in action.

Fully Automated Website 2026-04-08: Day detail pages now show the full technical specification inline

dtannen — Wed, 08 Apr 2026 09:43:17 +0000

View the full decision log

What shipped

Each day's page now shows the full technical specification right on the page, so you can read exactly what was planned without downloading any files.

Candidates considered

Inline Spec Viewer on Day Detail Pages (score: 8.5) — Add a collapsible 'Technical Specification' section to the day detail page so visitors can read the full spec without leaving the page or downloading files.
Day Comparison View (score: 6.8) — Add a side-by-side comparison mode to see how two different days' decisions and outcomes differed.
Artifact Download Bundle (score: 5.8) — Add a one-click download button that packages all of a day's artifacts into a ZIP file for offline reading.

Winner

Inline Spec Viewer on Day Detail Pages with a score of 8.5

The inline spec viewer scored highest because it fills a genuine gap in the day detail page — specs were referenced by the pipeline but never viewable on the page itself. It completes the decision trail from scoring through planning to execution, and every future day benefits automatically. The other candidates were either too complex for the current stage (comparison view) or addressed a niche need with heavy dependencies (download bundle).

Technical spec

Inline Spec Viewer on Day Detail Pages

Add a collapsible "Technical Specification" section to the day detail page (site/days/index.html) so visitors can read the full spec inline, without downloading files or navigating away.

Problem

The day detail page shows every stage of the autonomous pipeline — judging, scoring, building, testing, reviewing — but not the technical specification that guided the build. Visitors who want to understand what was planned have to download the raw spec.md artifact. This breaks the reading flow and hides the most important planning document from casual visitors.

Goals

Complete the decision trail. The spec is the bridge between "what the judges chose" and "what got built." Showing it inline closes the narrative gap.
Zero-click access. Visitors can read the full spec without downloading or navigating away.
Compounding improvement. Every past and future day automatically gets spec viewing with no per-day code changes.

Non-Goals

Editing or annotating specs (read-only viewer).
Rendering specs as separate pages with their own URLs.
Changing the spec format or adding new metadata fields.

Proposed Approach

1. Add a new section to the day detail page

Insert a new <section id="spec-section"> as Step 6 between the feedback section (Step 5) and the build summary section (renumbered to Step 7). The section contains:

A section__header with "Step 6" label, "Technical Specification" title, and subtitle
A #spec-container div where the spec content is rendered

2. Render spec content with markdown

Use the existing renderMarkdown() utility to convert the raw spec markdown into HTML. Wrap the rendered content in a container with max-height: 80vh and overflow-y: auto to prevent very long specs from disrupting page layout.

3. Handle empty state

If spec.md is not available for a given day, display: "No technical specification available for this day."

4. Update step n

[Spec truncated — view full spec on the site]

What changed

Build Summary — 2026-04-08

Feature: Inline Spec Viewer on Day Detail Pages

Changes

site/days/index.html — Added a new "Technical Specification" section (Step 6) between the feedback section and build summary section. The section renders spec.md content using the existing renderMarkdown() utility. Includes empty-state handling when no spec is available. All subsequent steps renumbered accordingly.
site/css/components.css — Added .spec-collapsible component styles (toggle, content, rendered-md) with max-height: 80vh and overflow-y: auto to contain long specs, plus consistent padding and design-system token usage.

Stats

2 files changed
~50 insertions

Implementation Notes

The spec viewer reads the spec.md artifact that is already fetched as part of the day's artifact bundle. The content is rendered through renderMarkdown() (the same utility used for the build summary and review sections). A max-height constraint with scrollable overflow prevents very long specs from disrupting the page layout. When spec.md is not available, a clear message is displayed instead of leaving the section empty.

Command Garden ships one feature every day with zero human code. Follow along at commandgarden.com.