[ac-pplx]

Summary

The templates page now opens on the templates, and says when a template has no published release.

Before this change:

• The page opened on the rolling warm-pool policy table, usually empty, with no page title, and listed the templates themselves third.
• A template with no build hash showed latest in its Hash column, the same text a built template's tag shows, whether or not it had a published release.
• The Network column's tags and Edit link overflowed into the Base Snap toggle.

Changes:

• The page has a Templates title, with the refresh action next to it.
• Sections are ordered templates, releases, node availability, then warm-pool policies.
• The Hash column's empty state is decided from the template releases the page already loads, not from content_hash, which comes from builder inventory. Once the releases have loaded, a present template that no release names shows no release, with the tooltip "No release has been published for this template: it may never have been built, every build may have failed, or its releases were unpublished." A published template that no builder node reports a build hash for shows —, with the tooltip "Published; no builder node reports a build hash for it."
• The Hash and Network columns are wide enough for their contents.

Build history and build failures are still not visible. The admin API has no route that lists a template's builds, only one that reads a build by job ID.

Stack

Independent of the other open console PRs. It edits ui/src/app/dashboard/templates/page.tsx, which #1250 also trims; whichever merges later may need a small rebase.

Validation

• npm ci, npm test (50 pass) and npm run build in ui/.
• The loop checks that the template whose only build failed shows "no release", that a published template presented without a build hash (a synthetic API answer) shows — with the "Published" tooltip, and that nothing is called unreleased while the releases are still loading.
• A Playwright loop against a local Kind stack with synthetic data: the seed template, a built custom template, and one whose only build failed. Run on main (production build) and on this branch (the Kind space-ui image).
• No new console errors, page errors or failed requests compared with main.

Visual confirmation

Before	After

Severity and risk

Severity: low.

Risk: low. Besides the layout, the Hash column's empty state changes meaning: it reports whether a release exists, read from the releases list. The first commit's message says the change is layout only and that "not built" means no release; the follow-up commit's message corrects both, and the squash keeps every commit message. Roll back by reverting the commits.

AI assistance: Claude Code wrote the code and this description, and ran the validation; a maintainer reviews it.

[github-actions]

Thanks for opening this pull request! A SPACE maintainer will take a look.

CONTRIBUTING.md explains how we review outside contributions.

Withdrawing this approval for now. Any feedback above still stands.

[the-gigi-pplx]

Review — no findings

No findings.

Verified against 7f0164ae023339e9a670571b589f9b8a6a00cdb3.

What I checked:

• The "no release" decision against the API. GET /admin/api/v1/template-releases (crates/libs/api/src/routes/admin/templates.rs:1712) is unpaginated and returns every release of every present template the actor can see. GET /templates lists templates without an org filter, but both routes require a managing-organization administrator, and visible_org_ids (crates/libs/api/src/routes/authz.rs:55) returns every org for that role. So a present template that no listed release names really has none, and the two lists can't disagree because of visibility.
• Template names are unique (ON CONFLICT (name) on insert, and the releases query joins on t.name), so keying the set by template_name can't mix two templates up.
• Release rows can be deleted (templates.rs:2008, and the template-delete path), so the tooltip's "its releases were unpublished" case exists.
• releasesLoaded stays false when the releases read fails (for example, a 403), so the column falls back to — instead of calling everything unreleased. It's in the column memo's dependencies.
• Moving the sections is a pure move. The warm-pool block is unchanged apart from its top margin, and Refresh still runs the full refresh over every section.
• Ran npm ci, npm test (50 pass), tsc --noEmit and npm run build in ui/ on this head.

What I didn't check: the visual layout (I didn't render the page), and the column widths at other viewport sizes.

[the-gigi-pplx]

Approved. No findings; details in the review comment above.