Feature Proposal: /rollcall - Component-level health verification after every change

[fg7000]

Hi Garry,

I've been using gStack extensively in my project (OperativeX, a local-first AI CTO orchestrator) and I've built an extension on top of it that I think would be valuable for the broader gStack community. Happy to contribute it back as a PR if you're interested.

The Problem

gStack's pipeline (CEO review, eng review, build, test, verify, ship) does a great job ensuring code quality at each stage. But there's a gap: after any code change, there's no automated way to verify that existing UI components still work. You fix the sidebar and accidentally break the status bar. Tests pass, typecheck passes, but the UI is visually broken. This is especially painful with multiple parallel Claude Code sessions. Each branch passes individually, but the merged result has regressions nobody checked.

The Solution: Guardian Roll Call

A /rollcall skill that lets you define a manifest of "guardians," where each guardian watches a specific component or system in your app. After ANY code change, you run /rollcall and every guardian reports its health status.
Think of it like a flight crew doing pre-flight checks. Pilot checks instruments, co-pilot checks controls, engineer checks engines. Nobody takes off until everyone reports green.
How It Works

Define a guardian manifest in your project (JSON or TypeScript). Each guardian has an ID, a name, and a list of health checks:

json{
"id": "G-UI-01",
"name": "Navigation Bar",
"checks": [
{ "type": "dom-exists", "selector": "[data-guardian='navbar']" },
{ "type": "dom-visible", "selector": "[data-guardian='navbar']" },
{ "type": "file-exists", "path": "src/components/Navbar.tsx" }
]
}

Run /rollcall after any change. The skill iterates through all guardians, runs their checks, and reports:

Guardian: Navigation Bar -> PASS (3/3 checks)
Guardian: Sidebar -> PASS (2/2 checks)
Guardian: Chat Panel -> FAIL (dom-visible failed)
Guardian: Input Bar -> PASS (2/2 checks)

RESULT: 3/4 PASS, 1 FAIL
BLOCKED: Fix Chat Panel before proceeding.

Block on failure. If any guardian fails, the agent cannot proceed to the next gStack stage. This prevents shipping regressions.

Check Types
The system supports these check types (extensible):

dom-exists - Is the element in the DOM?
dom-visible - Is the element actually visible (not display:none, not zero-size)?
dom-has-content - Does the element contain text content?
file-exists - Does a source file exist at the expected path?
file-contains - Does a file contain an expected string?

Server-side checks (file-exists, file-contains) run via the filesystem. Client-side checks (dom-exists, dom-visible, dom-has-content) run via /browse and evaluate in the browser console.
Why This Fits gStack

It fills the gap between /build and /verify. Right now, regressions slip through because there's no component-level health check.
It's the same philosophy as gStack: explicit, opinionated, structured. Not "hope nothing broke," but "prove nothing broke."
It integrates naturally with /browse (which gStack already ships) for the visual checks.
It's language/framework agnostic. The manifest is just selectors and file paths.

What I'd Contribute

A /rollcall skill (Markdown) with the methodology inline
A sample guardian manifest template
Documentation on how to set up guardians for any project
The check types and execution logic

Everything is generic, not tied to my specific project. I've been running this in production across 7 parallel agent workspaces and it's caught dozens of regressions that would have shipped otherwise.

Let me know if this is something you'd want in gStack. Happy to shape the PR however fits your vision for the project.

Best,
Faryar