feat(landing-demo): minimal LiveTemplate counter for docs landing page

[adnaan]

Summary

• Adds landing-demo/ — a 50-line main.go + 30-line counter.tmpl LiveTemplate counter.
• Designed to be deployed standalone as lt-landing-demo.fly.dev and same-origin proxied by the docs site so livetemplate.fly.dev can iframe a real, copy-pasteable LiveTemplate app on its landing page.

Why

The previous landing-page demo used tinkerdown's lvt fenced block + a markdown source binding. That worked but wasn't faithful to LiveTemplate — it was tinkerdown's data-binding API (.Done, .Id, auto-dispatched Toggle), not the controller-pattern API a LiveTemplate user would actually write.

This commit gives the landing page a real, copy-pasteable LiveTemplate app — the same controller + state + template a docs reader would write themselves.

Per-session ephemeral state (no DB). Multi-tab WebSocket sync within a session via lvt:"persist".

Test plan

• go run ./landing-demo from the examples module — counter renders, buttons present, no frame headers blocking iframe (X-Livetemplate-Websocket: enabled is the only LT-specific header).
• Deploy to lt-landing-demo.fly.dev and confirm reachable
• Iframe-embed in docs landing page and confirm WS connects + counter increments

🤖 Generated with Claude Code

[claude]

Code Review — landing-demo counter for docs landing page

Good concept and clean implementation overall. The controller/state pattern is correct, the Tier 1 HTML is well-formed, and the Dockerfile multi-stage build is solid. A few issues need to be addressed before merge, ranging from a hard blocker to minor nits.

---

🚨 Blocker: Missing E2E tests

landing-demo/ has no *_test.go file and is not added to test-all.sh. CLAUDE.md is explicit:

All examples must have chromedp E2E tests.

Every controller method (Increment, Decrement, Reset) must be exercised by at least one subtest. The adjacent counter/counter_test.go is a ready-made reference — the landing-demo test should be a trimmed version of it. At minimum the test suite should:

1. Verify the counter renders 0 on initial load
2. Click each named button and assert the counter value changes correctly
3. Verify lvt:"persist" works across a page refresh (counter retains state)
4. Assert no inline event handlers or raw template expressions are present

Also add "landing-demo" to WORKING_EXAMPLES in test-all.sh.

---

🚨 Blocker: Inline <style> block in counter.tmpl

counter.tmpl:16-20 contains:

<style>
    body { padding: 1.5rem; }
    .count { font-size: 3.5rem; text-align: center; margin: 0.5rem 0 1rem; font-weight: 600; }
    fieldset[role="group"] { max-width: 20rem; margin: 0 auto; }
</style>

CLAUDE.md prohibits this outright:

NEVER use <style> blocks in templates — all CSS in livetemplate.css

The .count styles should be extracted to livetemplate.css as a reusable utility class (it's a plausible candidate — a large centered number display is a pattern that could appear elsewhere). The body padding and fieldset max-width can likely be expressed through Pico's grid/container utilities instead of custom CSS. If you need custom CSS that isn't reusable, open a follow-up to discuss whether it belongs in livetemplate.css or if there's a semantic Pico alternative.

---

⚠️ Important: No graceful shutdown

The existing counter/main.go implements graceful shutdown (signal handling, HTTP server timeouts, WebSocket connection draining). The landing-demo uses:

log.Fatal(http.ListenAndServe(":"+port, mux))

For a Fly.io deployment (auto_stop_machines = "stop" is set in fly.toml), machines will be stopped and restarted frequently. Without graceful shutdown, in-flight WebSocket connections are dropped abruptly on each deploy or machine stop. The counter/main.go pattern is directly reusable here.

---

⚠️ Important: Default form action has no handler

counter.tmpl:25 uses <form method="POST"> with no name attribute. Per the Action Resolution Order in CLAUDE.md, if the form is somehow submitted without a named button click (e.g., pressing Enter, though there are no text inputs here), the framework resolves to the default action "submit" — which has no corresponding Submit() method on CounterController. This is low-risk given the form only contains buttons, but it's safer to either:

• Add name="increment" to the form itself (matching the conceptual default), or
• Be explicit that this is intentional via a comment

---

Minor: Not registered in test-all.sh

Even setting aside the missing test file, landing-demo needs to be added to WORKING_EXAMPLES in test-all.sh so ./test-all.sh picks it up. Right now it's silently excluded from CI.

---

Nit: Missing <article> card wrapper

CLAUDE.md specifies:

Use <article> as primary card container

The counter example uses <article> with <header>/<hgroup>. The landing-demo skips it entirely. If the intent is truly minimal (no chrome for the iframe embed), that's a reasonable call — but it should be noted in the README so readers know this is an intentional deviation for embed context, not the standard pattern to copy.

---

Looks good ✅

• Controller/State split is correct; lvt:"persist" on Count is the right approach for per-session ephemeral state with multi-tab sync
• Tier 1 HTML: standard <form method="POST"> + named buttons — no unnecessary lvt-* attributes
• Action routing via button name attributes is correct
• Dockerfile multi-stage build is clean; non-root user, pinned base images, template file copied to workdir at runtime (with comment explaining why)
• fly.toml config is sensible for a demo (shared CPU, 512 MB, auto-stop)
• go.mod version (go 1.26.0) matches the Dockerfile image tag — consistent

[Copilot]

Pull request overview

Adds a new landing-demo/ example: a minimal standalone LiveTemplate counter intended to power the docs landing page with a real, copy-pasteable app instead of the older markdown/tinkerdown-based demo. It extends the examples repo with a deployable docs-facing sample plus supporting docs and deployment config.

Changes:

• Adds a new landing-demo app with a minimal controller/state pair and matching template.
• Adds Fly.io deployment assets (Dockerfile, fly.toml) and per-app README for local run/deploy instructions.
• Updates the repo README to point readers at the hosted framework documentation.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
README.md	Adds a top-level link to the hosted LiveTemplate docs site.
landing-demo/README.md	Documents the new landing-page demo, its transport modes, and local/deploy usage.
landing-demo/main.go	Implements the minimal counter server and LiveTemplate handler wiring.
landing-demo/fly.toml	Adds Fly.io app/service configuration for standalone deployment.
landing-demo/Dockerfile	Defines a multi-stage image build for deploying the landing demo.
landing-demo/counter.tmpl	Adds the HTML template and controls for the embedded counter UI.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[claude]

Code Review — landing-demo counter

Overall this is a clean, well-scoped addition. The controller pattern is idiomatic, the template follows all the HTML boilerplate rules, and the CSP compliance check in the test is a nice touch. A few issues need addressing before merge.

---

Blocking

1. Sync() has no E2E test (CLAUDE.md violation)

The test file header comment says "exercise every controller method (Increment, Decrement, Reset, Sync)" but there is no Sync sub-test. CLAUDE.md is explicit: "Every exported method must be called in at least one E2E subtest." Cross-tab sync is also the differentiating feature of this demo — it deserves a test that opens a second context in the same session and asserts the peer tab reflects the updated count.

2. Sub-tests share implicit state across execution order

Decrement_Updates_Count begins with the comment "Counter is at 1 from the previous sub-test" and then asserts Count: 0. This means it silently depends on Increment_Updates_Count having run (and passed) first. CLAUDE.md rule: "Assert full page state after each mutation." Each sub-test should either navigate fresh or assert the full expected state rather than relying on inherited count.

---

Non-blocking but worth fixing

3. min_machines_running = 0 in fly.toml

This is the app that will be iframed on the docs landing page. With min_machines_running = 0 and auto_stop_machines = "stop", the first visitor after idle time will hit a cold start — the iframe will appear broken or empty during machine wake-up. Recommend min_machines_running = 1 for this specific deployment.

4. Decrement allows negative counts

s.Count-- has no lower-bound guard. A landing-page demo showing Count: -7 is a confusing first impression. Either clamp at zero:

func (c *CounterController) Decrement(s CounterState, _ *livetemplate.Context) (CounterState, error) {
    if s.Count > 0 {
        s.Count--
    }
    return s, nil
}

or document that negative values are intentional.

5. No HTTP POST fallback test

CLAUDE.md testing checklist: "HTTP POST tests should use button name encoding: "add=&field=value"." All three actions (increment, decrement, reset) are reachable via plain form POST (no JS). One sub-test hitting the form directly over HTTP would verify the no-JS path and serve as a regression guard.

---

Minor / Nit

6. Template has no heading

CLAUDE.md says "Use <hgroup> for title + subtitle." There is no <h1> or <hgroup> in counter.tmpl. For an iframe embed this may be intentional (saves vertical space), but a visually-hidden heading would help screen readers and still not affect layout:

<h1 class="visually-hidden">Live Counter</h1>

7. _ unused import alias is clear, but the ctx parameters are all unnamed _-able

All four controller methods accept ctx *livetemplate.Context but never use it. Marking them _ *livetemplate.Context would make the intent explicit and silence any linters that check unused parameters, consistent with how the Sync no-op is already explained in comments.

---

Summary

Issue	Severity
Sync() untested (CLAUDE.md violation)	Blocking
Sub-tests share implicit counter state	Blocking
min_machines_running = 0 on landing-page app	Should fix
Decrement can go negative	Should fix
No HTTP POST fallback test	Should fix
Missing heading in template	Nit
Unused ctx parameter not marked _	Nit

Happy to help draft the missing Sync cross-tab test if useful.

[claude]

Code Review — landing-demo counter for docs landing page

Overall this is a clean, well-scoped addition. The controller is minimal and the template follows every convention in CLAUDE.md. A few issues worth addressing before merge.

---

Bugs / Requirement Violations

chromedp.Sleep in Decrement_Stops_At_Zero (landing_demo_test.go:192)

chromedp.Click(`button[name="decrement"]`, chromedp.ByQuery),
chromedp.Sleep(300*time.Millisecond),  // ← violates CLAUDE.md

CLAUDE.md is explicit: "Use condition-based waits, not chromedp.Sleep. Sleep-based waits are flaky in CI and hide timing bugs." After the final decrement, you want to assert the count hasn't gone negative — replace the sleep with a positive assertion:

// After the third decrement, count should still be 0.
chromedp.Click(`button[name="decrement"]`, chromedp.ByQuery),
e2etest.WaitFor(`document.body.innerText.includes('Count: 0')`, 5*time.Second),

That's also a stronger assertion: it fails fast if the count went negative instead of waiting 300ms and then reading the DOM.

---

Test Coverage Gap

HTTP_POST_Fallback_Without_JS test self-describes the gap:

"Without a session cookie sent by http.Client, the increment might be on a different session."

As written, the test only asserts that <output aria-live="polite"> and <strong> appear in the response body — it doesn't verify that the counter actually incremented. It would be stronger with a cookie-aware http.Client:

jar, _ := cookiejar.New(nil)
client := &http.Client{Jar: jar}

// Reset
client.PostForm(base, url.Values{"reset": {""}})
// Increment
client.PostForm(base, url.Values{"increment": {""}})
// GET — same session, should see Count: 1
resp, _ := client.Get(base)
// assert body contains <strong>1</strong>

Without this, the sub-test proves the route is reachable but not that PRG routing (increment → Increment()) works on the HTTP path.

---

Minor / Style

Testing package imported in production main.go (main.go:14,63–64):

import e2etest "github.com/livetemplate/lvt/testing"
// ...
mux.HandleFunc("/livetemplate-client.js", e2etest.ServeClientLibrary)
mux.HandleFunc("/livetemplate.css", e2etest.ServeCSS)

This appears to be a project-wide pattern (other examples do the same for LVT_DEV_MODE), so it isn't a blocker, but it means a _test-intended package is compiled into the production binary. If the e2etest package ever pulls in test-only transitive deps, this will silently inflate the binary. Worth tracking as a project-level refactor (e.g. a small livetemplate/devserver package that isn't under */testing).

json:"count" struct tag (main.go:21):

Count int `json:"count" lvt:"persist"`

Is the json tag load-bearing here (session serialization format)? If so, a one-line comment would make the intent clear; if not, it can be dropped. Not a bug either way.

---

What's Good

• Template is textbook Tier 1. Correct method="POST" form, button name attributes for action routing, no lvt-* attributes used where standard HTML suffices, CSP-compliant (no inline handlers or styles).
• Accessibility is solid. <output aria-live="polite"> means screen readers announce count changes; <h1 class="visually-hidden"> provides a document landmark without cluttering the visual design.
• Cross-tab sync test is excellent. Testing Sync() via two chromedp tab contexts sharing the same allocator/cookie jar is exactly the right approach — it exercises the actual WebSocket + SessionStore path.
• Dockerfile is well-structured: multi-stage, non-root runtime user, explicit RUN test -d landing-demo guard against stale-ref deploys, and the comment explaining the cwd requirement for template loading is helpful.
• Every controller method is exercised (CLAUDE.md checklist satisfied): Increment, Decrement, Reset, Sync.
• Full page state asserted after mutations — e.g. Decrement_Stops_At_Zero steps through 0→1→2→1→0 checking the counter text at each step rather than just the final state.

---

Summary

Two concrete items to fix before merge:

1. Replace chromedp.Sleep with a condition-based wait in Decrement_Stops_At_Zero.
2. Strengthen HTTP_POST_Fallback_Without_JS with a cookie-aware client so it actually validates the POST→Increment path.

The e2etest import in main.go and the json tag are worth a follow-up but not blockers.

[claude]

Code Review

Overview

Adds landing-demo/ — a minimal LiveTemplate counter (increment / decrement / reset) with per-session ephemeral state and cross-tab sync via Sync(). Intended to be deployed standalone and iframed on the docs landing page. The implementation is clean and compact, the template follows all CLAUDE.md conventions, and test coverage is broad. A few issues below, one of which is a blocker.

---

Blocker

main.go imports a testing package in production code

import (
    e2etest "github.com/livetemplate/lvt/testing"
)
...
mux.HandleFunc("/livetemplate-client.js", e2etest.ServeClientLibrary)
mux.HandleFunc("/livetemplate.css", e2etest.ServeCSS)

github.com/livetemplate/lvt/testing is a test-only package. Importing it in main.go pulls test infrastructure into the production binary and unnecessarily widens the dependency surface. The other examples guard these routes behind a DevMode check and keep the server code free of e2etest imports. This should be gated:

if livetemplate.DevMode() {
    mux.HandleFunc("/livetemplate-client.js", e2etest.ServeClientLibrary)
    mux.HandleFunc("/livetemplate.css", e2etest.ServeCSS)
}

Or, if the framework provides a livetemplate.ServeDev(mux) helper (as several other examples use), prefer that. Either way, e2etest must not be a production import.

---

Bugs / Correctness

chromedp.Sleep in Decrement_Stops_At_Zero (CLAUDE.md violation)

chromedp.Click(`button[name="decrement"]`, chromedp.ByQuery),
chromedp.Sleep(300*time.Millisecond),   // ← banned by CLAUDE.md

CLAUDE.md is explicit: "Use condition-based waits, not chromedp.Sleep." After the final decrement, assert textContent === '0' with e2etest.WaitFor instead of sleeping. The sleep masks timing bugs and is flaky in CI.

chromedp.Click(`button[name="decrement"]`, chromedp.ByQuery),
e2etest.WaitFor(`document.querySelector('output strong')?.textContent === '0'`, 5*time.Second),

HTTP response body may be truncated

buf := make([]byte, 8192)
n, _ := resp.Body.Read(buf)
body := string(buf[:n])

io.Reader.Read is not guaranteed to fill the buffer in one call. If the rendered page exceeds 8 KB (Pico CSS <link> tags, framework scripts, etc.) the assertion on output aria-live="polite" could silently pass or fail non-deterministically. Use io.ReadAll:

import "io"
...
body, err := io.ReadAll(resp.Body)
if err != nil { t.Fatalf(...) }

---

Test Coverage

HTTP_POST_Fallback_Without_JS doesn't verify state

The test sends a POST reset + POST increment, then GETs the page — but because http.PostForm uses a cookieless client, the increment is on a different session. The test therefore only checks that the counter element exists in some response, not that HTTP POST actually mutates counter state. The comment acknowledges this, but it means the Tier-1 HTTP path isn't meaningfully validated.

Consider using http.Client with a CookieJar so that the POST and GET share a session:

jar, _ := cookiejar.New(nil)
client := &http.Client{Jar: jar}
client.PostForm(base, url.Values{"reset": {""}})
client.PostForm(base, url.Values{"increment": {""}})
resp, _ := client.Get(base)
// now body should contain <strong>1</strong>

---

Minor

No Submit() method on the controller

The form has no name attribute, so a submission with no button name (e.g. pressing Enter in a hypothetical input field, or a JS call) would route to the default "submit" action, which has no handler. In the current template this can't happen in practice, but it's worth noting in case the template grows later. A no-op Submit() method would make the routing intent explicit.

Dockerfile clones from GitHub at build time

RUN git clone --depth=1 --branch=${EXAMPLES_REF} https://github.com/livetemplate/examples.git .

This makes image builds non-hermetic (network-dependent, non-reproducible if the branch tip moves between builds). For the fly deploy workflow this is likely intentional and the existing EXAMPLES_REF arg plus the guard check are a reasonable mitigation, but it's worth knowing that two deploys from the same --build-arg EXAMPLES_REF=main can produce different images if commits land between them.

---

What's Working Well

• Template follows CLAUDE.md boilerplate exactly — correct <html lang="en">, color-scheme meta, Pico CSS, conditional DevMode script loading.
• <output aria-live="polite"> is the right element for a live numeric counter — screen readers will announce updates without extra ARIA ceremony.
• The Sync_Propagates_To_Peer_Tab test is solid: it opens a real second tab in the same browser context (shared cookie jar), drives both directions, and asserts full state at each step.
• UI_Standards_Pico_And_CSP_Clean inline-handler + inline-style check is a nice guard that will catch regressions automatically.
• resetCounter helper ensures every sub-test starts from a known baseline — good pattern.
• Dockerfile uses a non-root user and multi-stage build — correct.

---

Required before merge: fix the e2etest production import. The chromedp.Sleep and io.ReadAll issues should also be addressed — both are straightforward changes.

[claude]

Code Review

Overview: Adds landing-demo/ — a minimal LiveTemplate counter designed to be deployed as lt-landing-demo.fly.dev and embedded via iframe on the docs landing page. The whole app is ~70 lines of Go + 32 lines of HTML, and it ships with a Dockerfile, Fly deployment config, and a suite of chromedp E2E tests.

This is clean, well-documented work. One critical concern (production import of a test package) and a few smaller issues below.

---

Critical

main.go imports e2etest (a test package) in production code

import (
    e2etest "github.com/livetemplate/lvt/testing"
)
// ...
mux.HandleFunc("/livetemplate-client.js", e2etest.ServeClientLibrary)
mux.HandleFunc("/livetemplate.css", e2etest.ServeCSS)

This bundles test infrastructure into the production binary and couples a live deployment to the test package's import path. The handlers behind these routes are only reached in dev mode (when LVT_DEV_MODE=true), but they're registered unconditionally. If the test package evolves its API or grows new transitive dependencies, this will silently affect the production binary.

The standard fix is a build-tag split: put ServeClientLibrary/ServeCSS registration in a main_dev.go (with //go:build dev) and a no-op stub in main_prod.go. Or — if this e2etest.Serve* pattern is already established in other examples — cite the precedent so reviewers know it's intentional.

---

Moderate

Decrement_Clamps_At_Zero_Via_HTTP has dead code and doesn't verify the clamp

jar, err := url.Parse(base)
_ = jar   // never used
_ = err   // never used

url.Parse was presumably left over from an earlier draft. More importantly, because http.PostForm sends no cookie jar, each POST lands in a fresh server session — so the reset and the decrement are on different sessions. The test only verifies the endpoint doesn't 5xx, not that clamping works. That's stated in the comments, but the dead code should be removed and either:

• Accept the test for what it is (panic/5xx guard) and rename it to make that clear, or
• Thread a real *http.Client with a cookie jar through the calls so session state is actually shared.

Sync_Propagates_To_Peer_Tab is permanently skipped with no tracking issue

The cross-tab sync is the most prominent claim on the landing page. Skipping the test with an inline comment works short-term, but there's no GitHub issue or TODO reference to track it. Please open a follow-up issue and link it in the skip message so it doesn't quietly stay skipped forever.

---

Minor

README line-count is off

README.md says "main.go (~50 lines)" but the file is 69 lines. Small thing, but the PR description says "50-line main.go" too.

HTTP_POST_Fallback_Without_JS session isolation is acknowledged but the assertion is very weak

if !strings.Contains(body, `output aria-live="polite"`) && !strings.Contains(body, "<strong>") {

The && means the test passes as long as either string is present. If the <output> element is missing but a <strong> exists elsewhere in the page, the test would still pass. Consider using || (fail if either is missing) or tightening to a single specific selector.

iframe embedding — headers

The PR description mentions "no frame headers blocking iframe (X-Frame-Options: enabled is the only LT-specific header)". Is the framework not setting X-Frame-Options: DENY or frame-ancestors by default? If it does, this needs a config toggle — worth calling out explicitly so the Fly deploy isn't blocked on this at integration time.

---

What's good

• Template fully follows CLAUDE.md conventions: correct boilerplate, Pico CSS only, no inline styles, no inline event handlers, hidden attribute for visibility, proper <output aria-live="polite"> for accessibility.
• Tier 1 throughout — buttons use name attributes for action routing, form has method="POST", no unnecessary lvt-* attributes.
• The resetCounter helper and the comment explaining why clicking Reset on an already-zero counter is avoided are excellent — this is exactly the kind of non-obvious constraint that belongs in test comments.
• Dockerfile: multi-stage, non-root user, static binary, fail-fast ref check. Solid.
• The Sync() method explanation in both the code comment and README is genuinely helpful; the framework's Sync reservation is not obvious without it.

[claude]

Code Review — landing-demo counter

Overview

Adds a minimal, copy-pasteable LiveTemplate counter app intended to be iframe-embedded on the docs landing page. Good rationale: the previous tinkerdown-based demo used a different data-binding API, so this gives visitors a real example they can run themselves. The controller is clean Tier 1 code, the template is tight, and the Dockerfile follows good security practices.

---

Issues

Bug / Dead Code — Decrement_Clamps_At_Zero_Via_HTTP

jar, err := url.Parse(base)
_ = jar // session continuity is per-cookie; for this test we just verify the controller logic
_ = err

url.Parse returns a *url.URL, not a cookie jar, so this code does nothing useful. If the intent was to construct an http.CookieJar for session continuity, it would need cookiejar.New. Remove these three lines — they're noise that may confuse future readers.

Weak HTTP Tests — No Cookie Jar

Both Decrement_Clamps_At_Zero_Via_HTTP and HTTP_POST_Fallback_Without_JS use bare http.PostForm / http.Get, so each request lands in a new server session. The tests can only assert "server didn't 500"; they can't verify state across requests. That's acknowledged in the comments, but:

• HTTP_POST_Fallback_Without_JS should be renamed to reflect what it actually asserts (e.g., HTTP_POST_Fallback_Does_Not_Crash) to avoid misleading future maintainers.
• The clamp logic in Decrement_Clamps_At_Zero_Via_HTTP is only covered because the controller code is simple enough to trust by inspection. Consider adding a small unit test for Decrement and Reset directly if you want deterministic coverage of the clamp without a cookie jar.

CLAUDE.md Requirement — Every Controller Method Must Have a Non-Skipped Test

Every method must be called in at least one E2E subtest.

Sync() is skipped. The skip reason is well-documented and the tracking issue reference (#94) is helpful, but this means a core advertised feature (cross-tab sync) has zero automated coverage at merge time. Either:

• Mark the skip with t.Skip(...) and file landing-demo: re-enable Sync_Propagates_To_Peer_Tab e2e test #94 before merging (acceptable), and add a note to the PR description that this is a known gap; or
• Add a minimal unit-level smoke test that calls Sync() directly on the controller to confirm it returns unchanged state.

Unnecessary json Tag on State Struct

type CounterState struct {
    Count int `json:"count" lvt:"persist"`
}

None of the other example state structs in this repo use json tags on their fields. The lvt:"persist" tag handles framework serialization. Unless there's a specific reason Count needs a lowercase JSON key (e.g., a separate JSON API endpoint this demo doesn't have), drop json:"count" to stay consistent with the rest of the examples.

resetCounter Comment Hints at Possible Framework Bug

clicking Reset on an already-zero state produces an empty diff that the LiveTemplate client appears to never receive a reply for, which then blocks the next click

This is working around what might be a framework-level issue (WS client wedging on no-op diffs). Worth filing a separate issue so it's tracked rather than only documented in a test helper comment.

---

Minor Notes

• fly.toml min_machines_running = 1: The comment explaining the rationale (cold-start iframe delay) is exactly right. One thing to double-check: auto_stop_machines = "stop" combined with min_machines_running = 1 means Fly keeps exactly one machine alive always. That's the intended behavior, but it does mean ongoing compute cost even when the docs site is idle. Fine for a landing page — just worth a callout in the infra notes.

• Dockerfile RUN go mod download -C ..: Slightly non-obvious that this downloads the parent module's deps while WORKDIR is /src/landing-demo. The comment in the Dockerfile explains the counter.tmpl cwd requirement but not the -C ... A one-line comment here would help.

• Sync_Propagates_To_Peer_Tab skip message: The skip string is long. Keep it; the detail is valuable. Just make sure landing-demo: re-enable Sync_Propagates_To_Peer_Tab e2e test #94 actually gets filed before this merges.

---

What's Working Well

• Template is clean Tier 1 with correct boilerplate, Pico CSS, no inline event handlers, no inline styles — fully CSP-clean.
• aria-live="polite" on <output> is a nice accessibility touch; screen readers will announce counter changes without a full-page reload.
• <h1 class="visually-hidden"> correctly keeps the iframe semantically correct without showing a heading in the visible UI.
• Dockerfile uses a non-root user, multi-stage build, CGO_ENABLED=0, and pinned Alpine version — good production hygiene.
• The Sync() no-op + lvt:"persist" pattern is well-explained in both the README and inline comments.
• resetCounter helper in the test uses a JS-evaluate read (passive) before conditionally clicking — smart approach to avoid the no-op-diff wedge.
• Decrement clamp with explanation ("Count: -7 reads as broken") is a good user-experience rationale, not just defensive coding.

---

Summary

Two actionable items before merge:

1. Remove the dead url.Parse / _ = jar lines in Decrement_Clamps_At_Zero_Via_HTTP.
2. Drop the json:"count" tag from CounterState.

The skipped Sync test and the weak HTTP-session tests are known gaps with acceptable explanations, but rename HTTP_POST_Fallback_Without_JS to something that reflects what it actually asserts. File #94 if it isn't already open.

Everything else looks solid.