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

dsh-aris-panel

v0.3.1

Published

ARIS research-workflow skills + interactive workbench panel for DeepSeek Harness (user fork of dsh-aris: upstream ARIS skills synced to 341f914 plus a full upstream snapshot under aris/, human-in-loop-refine (human-in-the-loop revision) and verify-manager

Readme

ARIS on DeepSeek Harness

English | 中文

The dsh-aris distribution branch. The full ARIS project — every workflow, the docs, and the other host adaptations — lives on main.

Runs the ARIS research workflow inside DeepSeek Harness: all 83 upstream ARIS skills (synced to upstream 341f914) plus 3 local skills and 9 Claude reviewer overlays in the native skill catalog, with cross-model adversarial review through Codex.

The skills are unmodified. This bundle is one configuration layer plus a short adapter — it patches no Harness code and forks nothing.

Install

dsh plugin --profile web add dsh-aris

Restart the profile afterwards; plugin code loads at startup, so reloading the page is not enough.

dsh plugin shells out to pnpm, which the Harness does not bundle. Without it on PATH the install exits before doing anything.

Prerequisites

Codex CLI, installed and authenticated. It is the independent reviewer. The bundle spawns codex mcp-server and never overrides its model or reasoning effort — ~/.codex/config.toml is the reviewer posture contract. ARIS expects a non-DeepSeek family at xhigh:

model = "gpt-6-astra"
model_reasoning_effort = "xhigh"

If Codex cannot start, the Harness fails to boot rather than running a composition with no reviewer. That is deliberate: ARIS without an independent reviewer is not ARIS.

A DeepSeek API key, through the Harness Models page or DEEPSEEK_API_KEY.

Behind an HTTP proxy, start the Harness with NODE_USE_ENV_PROXY=1. Node's fetch ignores http_proxy otherwise, and model requests fail with TRANSPORT. It must be set when Node starts; configuration cannot repair an already-started process.

Optional — bound the executor too. ARIS's reviewers already carry scope limits: the block that forbids proposing hashes, defensive scaffolding, corner-case hardening, and over-mechanized judgement is embedded in the skills that produce review prompts, and applies with no setup. Nothing bounds the executor the same way. Two ways to close that, and they are different things:

  • ARIS's own limits, one flag. The aris-scope-limits row ships disabled; set disabled: false in your profile's patch to apply the same block to the executor. It reads the packaged skills/shared-references/review-scope-limits.md at load, so the reviewer path and the executor path cannot drift apart. Off by default because it spends tokens on every request.
  • The full HERO contract. Paste its canonical block into the project's AGENTS.md or CLAUDE.md, or into $DSH_HOME/AGENTS.md for every dsh project — the Harness loads those files itself. This bundle does not vendor HERO's text; its canonical home is HERO's own RULES.md.

Verify

dsh --profile web --dump-config | grep -A2 aris-

Then, in a session, type / — the skill menu lists the ARIS skills. To check the part that matters, ask the model to call mcp__codex__codex with a trivial prompt, report the threadId it can see, then continue that thread once with mcp__codex__codex-reply. A visible threadId is what makes multi-round review work.

The ARIS tab

In the Web UI a session gains an ARIS tab after Chat and Trajectory (order: 15, between Trajectory and LiveBench). The tab has two layers:

  • A read-only run-status block on top: it shows what the reviewer and the loop's own artifacts say, and never writes, advances a round, or turns a score into a completion decision. It reads review-stage/REVIEW_STATE.json from the session's workspace, so it stays empty until an auto-review-loop run finishes a round there.
  • The interactive ARIS workbench below it: skill launcher, workflow guide, idea board, experiments, wiki graph, and audit chain. It reads workspace artifacts through two JSON endpoints — /api/aris-run (run status) and /api/aris-wb (workbench) — and is always bound to the current session. The old bottom-left full-screen workbench overlay is gone; the composer stays available while the tab is open.

The top run-status summary is the reason the tab exists: who reviewed this round, and whether ARIS could verify that the reviewer belongs to a different model family than the executor. On the Codex backend that verification is unverified by design — Codex reports its own model, but nothing independently attests the executor's, so ARIS records identity_assurance: caller_declared. Read it as "route-consistent, not attested".

Two honest limits are shown in the tab and worth repeating: state is written when a round finishes, not continuously, so a long round displays the previous one; and completed means the loop ended — a positive assessment or the round cap — never that the work was acquitted.

Local additions (dsh-aris-panel)

  • Claude reviewer route — 9 thin overlays. research-review, research-refine, auto-review-loop, kill-argument, proof-checker, paper-plan, paper-figure, paper-write and auto-paper-improvement-loop each have a <name>-claude overlay that loads the latest base skill in full and swaps only the reviewer transport (Codex MCP → claude-review MCP). Orchestrators switch to them automatically when $ARGUMENTS carries reviewer: claude or the user asks for Claude as the reviewer; the six audit skills without an overlay stay on Codex and the report says reviewer: claude (partial). Rebuild with python tools/build_claude_overlays.py after every upstream sync; test/test_claude_overlays.py fails when upstream introduces a reviewer tool the overlay does not map.
  • /verify-manager — idea verification in _verify- mirrors. One call runs falsifiable hypothesis + pre-registered criteria → plan and tasks → run (with baseline reproduction) → analysis against the baseline → next ideas, inside _verify-<mainline-dir>/<slug>/. The mainline stays read-only; a supported result is promoted only through a handoff note. Triggered by plain requests such as 「我有个想法需要验证」 or 「做个简单的验证实验」; requests that say full-scale / mainline / formal experiment / baseline runs go to /experiment-plan → /experiment-bridge instead.
  • /human-in-loop-refine — after an ARIS draft exists, folds the human's critiques, requirements, reference papers (innovations and implementation ideas extracted) and wild ideas into a revision staged under _refine/rNN/. Every change is triaged as evidence-backed / needs-verification / rejected; it contains /verify-manager, which runs each needs-verification item and feeds the verdict back. Mainline files change only after the human confirms.
  • aris/ — upstream snapshot. A full copy of the ARIS repository (commit in aris/UPSTREAM.txt, without .git and .env) for reference and re-sync; DSH loads skills only from skills/.
  • /gpt-image-2 — bridge to the local OpenAI-compatible image route, used by paper-writing's illustration: gpt-image-2.
  • Deep-audit tier max, not ultra. Upstream pins deep audits at gpt-6-astra + ultra; this install's Codex catalog lists gpt-6-astra levels none/high/xhigh/max, so the corpus is localized to max (see the note in shared-references/reviewer-routing.md).

What the layer changes

| Row | Effect | |---|---| | agent-default-model | executor becomes deepseek-flash | | aris-skills | mounts the skill corpus (83 upstream + 3 local + 9 Claude overlays), publishes ARIS_REPO, restores Codex's threadId, serves the ARIS tab | | aris-codex | codex mcp-server over MCP, 20-minute call budget, pinned to a stable working directory |

The corpus mounts at the bundled rank, so a project or user skill of the same name wins. The executor default is a deployment default, not a lock: a saved model setting or a per-session choice overrides it.

Developing against a checkout

ARIS_REPO=/absolute/path/to/aris NODE_USE_ENV_PROXY=1 \
  dsh --profile web --patch /absolute/path/to/aris/dsh/checkout.patch.yml

Skill edits take effect without a restart. ARIS_REPO is required; without it the load fails naming the variable.

This overlay is not equivalent to the installed bundle: it cannot restore Codex's threadId, so multi-round codex-reply — and therefore the hard-tier Debate Protocol — works only through the installed bundle. The two are mutually exclusive: applying the overlay to a profile that already has the bundle fails on a duplicate row id. Remove one.

Known limits

  • Tracks a Harness window, declared as a peer dependency. DeepSeek Harness is a developer preview; this bundle declares @deepseek-ai/dsh >=0.1.7-rc.2 <0.3.0-0 as an optional peer. The transport test passes against 0.2.1-rc.2 (and passed against 0.2.0-rc.2); the HostConnectionFetch registry it uses exists in every release of that window. The dsh peer-dependency gate reads the range: an incompatible runtime skips the whole bundle with a line in the boot log. On a newer runtime, re-run node node_modules/dsh-aris-panel/test/transport-smoke.mjs, then widen the range, or grant the exact-version exemption with dsh plugin allow-version.
  • The panel's browser transport is HTTP, not an RPC channel. dsh's generic channel registry (connection.rpc.handle) resolves webServer from Connection's own context, which dsh does not inject there (0.1.7-rc.2 through 0.2.1-rc.2), so an out-of-tree channel registration throws and every call dies as HTTP 405 from the SPA fallback. ARIS mounts exact Fetch routes on the /api prefix instead (HostConnectionFetch.register), served behind dsh's Host/Origin fence and browser-session cookie; since 0.2.1 the shared handler also serves exact routes to the owner peer only, and a browser session is that owner. test/transport-smoke.mjs pins both halves, including the 403 for a non-owner peer; it cannot cover the carrier's own auth path, so verify a live host with POST /api/aris-run and /api/aris-wb — 400 means mounted, 403 means the owner gate refused, 404 means not mounted.
  • No dsh packages are declared as npm dependencies. In-box packages are host-provided and resolve from the Harness installation through the profile module fallback. The Harness's own rule keeps @deepseek-ai/dsh-* out of dependencies, and the packages version in lockstep with the CLI, so any range this bundle pinned would fight the version the user already has installed. The peer range above is a compatibility declaration, marked optional so it never pulls a second copy of the runtime.
  • web_fetch is off. Stock dsh ships it disabled and this bundle does not enable it, which would mean depending on a provider package. Skills that reach the web use web_search, or bash with curl.
  • Reviewer thread continuity is process-local. A Harness restart, or any MCP reconnect that replaces the Codex child, loses saved threadIds. Rounds after that start fresh; review-stage/REVIEWER_MEMORY.md remains the durable record either way.
  • Codex's own reasoning is not in the Harness log. Only the verdict returns. The call arguments and the verdict are logged; the reviewer's intermediate work stays on the Codex side.
  • A verdict over 50 KB is spilled to a file with a preview left in context. Raise maxInlineBytes on the spill-policy row if your reviews run longer.