npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2026 – Pkg Stats / Ryan Hefner

@shapeshift-labs/frontier-loom-ui

v0.1.41

Published

Dark operator UI for Loom and Frontier swarm runs.

Readme

@shapeshift-labs/frontier-loom-ui

Full-height dark operator UI for Loom and Frontier swarm workspaces.

The UI reads the dashboard snapshot API from @shapeshift-labs/frontier-swarm-codex and projects the shared Frontier substrate from @shapeshift-labs/frontier-run, @shapeshift-labs/frontier-lease, @shapeshift-labs/frontier-test, and @shapeshift-labs/frontier-swarm-git. The browser surface is read-only: it focuses on workspace-lifetime progress, active agents, tasks, evidence/admission status, recent events, gate health, lease state, git apply/workspace evidence, and loaded sources.

The dashboard is global by design. It rolls up agent-runs/, .loom/queues/, coordinator decision overlays, frontier-run JSONL, semantic lease records, gate execution records, swarm-git apply ledgers/workspace proofs, and currently running workers from the selected workspace. It is not possible to pin the UI to a single run from the CLI or server options; individual run artifacts are loaded only as inputs into the lifetime workspace view.

The overview and success views surface landed/applied ledger counts, health, token load, and timing summaries with compact dark cards. The metrics view includes small, dependency-free dark chart primitives for API-provided health, bucketed time-series progress, context/token load, failure and ownership pressure, and semantic admission counts when those fields are present in the snapshot. Older snapshots still render from jobs and events as a fallback. The page remains full-height with scroll-contained panels so dense workspaces do not push the document body.

frontier-loom-ui --cwd /path/to/workspace

Loom can launch the same package:

loom ui --cwd /path/to/workspace
loom swarm dashboard --cwd /path/to/workspace

The browser app is rendered with Frontier DOM JSX via @shapeshift-labs/frontier-dom/jsx-runtime; frontier.config.mjs declares the Frontier Framework surface and route evidence. The app frame separates API availability from run health, so an online dashboard with rejected or attention-needed jobs is shown as an online service with run issues rather than as an offline UI.

Near-term UI Backlog

  • History: a read-only git-style graph of worker outputs, coordinator joins, semantic replay outcomes, and landed changes. The tab should focus on the visual graph first, with hover/details for ticket id, files, evidence, tests, model/panel result, and acceptance or rejection reason.
  • Performance: a chart-first view of tokens, runtime, cache hit rate, waste, and outcome quality over time. This needs a charting-library research pass before implementation, and should include whether panel, tournament, or RSI routing changes are improving workflow efficiency across runs.
  • Testing: a high-level quality view for active work and the broader project. It should show pass/fail state, fuzzing results, oracle coverage, recent failures, and whether each active task has enough verification evidence. Raw run artifacts should remain ticket drill-downs rather than becoming the top-level tab.