The original repository has been deleted or made private. This page is an archival snapshot from indexing time; the install command may no longer work.

deepseek-heartflow avatar

deepseek-heartflow

HeartFlow (心虫) as a DSH plugin — AGI 第1层辨别门禁: heartflow_check tool + automatic output supervision

PluginAI Models
Verification
L4 · Install tested
stale
Risk
Out of scope
Health
Inactive
Trust
Silver

Install verification: sandbox install passed (L4) · runtime test (L5) pending · tested on dsh 0.1.1-rc.2 · last checked Install verification details →

Data as of (UTC)

What it doesAI

HeartFlow DSH plugin provides heartflow_check tool and automatic output supervision as an AGI Layer 1 discrimination gate.

  • heartflow_check tool
  • Automatic output supervision
  • AGI Layer 1 discrimination gate
aiAI

Capability tags are AI-inferred or rule-extracted from the README (see badge) — vocabulary-limited, not install-verified. AI = inferred; README = literal keyword from the readme.

Installation

dsh plugin --profile web add @yun520-1/deepseek-heartflow@0.6.8

security scan passed · npm package v0.6.8

Install method: npm · sandbox install passed (L4) · runtime test (L5) pending · verified on dsh 0.1.1-rc.2

Trends

Four lines, four questions: total stars, stars gained this week, cumulative downloads, downloads this week. The GitHub pair comes from real-read sampling — a rotating daily shard, so one plugin is re-read roughly every 5–14 days, sparser than npm; the npm pair has a value on every snapshot day. The two cumulative panels are smoothed curves with no sample markers; the two weekly panels keep their raw bars and add a 4-week moving-average trend line that strips single-week noise down to the direction of travel.

GitHub stars
5★

current (registry 2026-08-16) · 0 samples; a smoothed curve through every sample — not a daily series

Only 0 points (< 3): no chart yet

no data yet

Weekly star gain
—★

Bars = the delta between two samples 5–14 days apart (negative points down, faint bars contain reconstructed points); line = 4-week moving-average trend

Only 0 points (< 3): no chart yet

no data yet

Cumulative downloads
—

Reconstructed backwards from the current total using daily downloads (gaps are not interpolated)

Only 0 points (< 3): no chart yet

no data yet

Weekly downloads
173

Bars = the snapshot’s last-week rolling window (official npm + npmmirror combined); line = 4-week moving-average trend — the shape of weekly demand, not a user count

08-17 → 08-26 · 7 points

npm snapshots 78 · 7 observed days · mirror included from 2026-10-18weekly board —total board —downloads ≠ unique usersstar weekly —

Verification & Compatibility

Grouped by plugin version: each card lists the dsh versions actually tested against that artifact version and their install verdicts (L5 wins). Untested combinations are omitted — absence means untested, never assumed compatible. L1–L3 are a plugin-level static archive (independent of the dsh version — the same verdict on every dsh row): they sit in each row's level grid next to L4/L5, marked "static", while their evidence is stored once per plugin inside that row's "checks & evidence" instead of being duplicated per version.

External credentials (plugin-level): none detected

Declared DSH compatibilityfrom package.json · peerDependencies
only dsh 0.1.x (0.1.0-rc.6 and up, below 0.2.0)

Based on 1 requirement(s) across 3 @deepseek-ai/dsh-* packages.

raw ranges^0.1.0-rc.6 ×3

✗ Running dsh 0.2.2-rc.3 is outside the declared range — the official install gate rejects it (incompatible-version).

To force-install, grant an exact-version exemption: dsh plugin allow-version deepseek-heartflow@0.6.8 0.2.2-rc.3 (the exemption lives in the local profile; this site does not assume one)

Deciding channel: no engines.dsh declared, so every dsh* peer is checked (workspace:^ | ~ | * counts as the running version).

Whether it actually runs is a separate question → see the measured matrix below (L1–L5).

Install compatibility matrix (rows = plugin versions〔latest 5〕, columns = dsh versions〔latest 5〕)
At-a-glance → evidence in the cards below
plugin \ dshdsh 0.1.1-rc.2
0.6.8·
Install compatibility (by plugin version, dsh versions within)
Legend:✓ L5 runtime verified○ ecosystem plugin◼ ecosystem app✗ failed
0.6.8npm2026-08-24

@yun520-1/deepseek-heartflow

No runtime install test for this version (static scan only) — compatibility unknown, never assumed.

Only the latest 3 published versions are shown; source-snapshot (commit hash) groups, unstated groups and older versions are omitted — the full archive stays in the data layer (snapshot/unstated groups appear only when a plugin has no published version).

Author badges

Embed the dsh.so badges in your README to show this plugin's automated security-scan and install-test status:

dsh.so risk badge
`[![dsh.so risk](https://cdn.dsh.so/badge/deepseek-heartflow.svg)](https://www.dsh.so/artifact/deepseek-heartflow/?ref=badge)`

dsh.so is an independent community project, not affiliated with or endorsed by DeepSeek AI. Badges are maintained by dsh.so; embed links carry a ?ref= attribution parameter.

Security Report

Two automated layers, neither a manual review: a static scan (per-plugin rule checks) and a model-driven dynamic security audit that covers only the subset static-flagged at warn or above and never executes plugin code.

deepseek-heartflowAutomated review · daily

Static high; dynamic medium (authoritative when present) → overall medium.

static high→dynamic medium→overall medium
dynamic findings0 critical·0 high·2 medium·2 low
mediumoverall · medium
1static scan · vet primaryvet AST static analysis (npm artifact or git source)
plugin versionv0.6.8dsh manifest
scanned version0.6.8npm2026-08-25
current version0.6.8same version
vet verdictsuspicious · npm

Vet is an AST static scan (npm artifact or git source).

2model reads redacted source context · never executes plugin code
highest grademedium
merged intooverall medium
audited at2026-10-24
audited artifactnpm 0.6.8
findings0 critical·0 high2 medium / 2 low hidden
show 4 audit findings
  • mediumEngine modules are require()d from environment-variable controlled paths without validationlib/index.js:55

    loadEngine() builds candidate lists from process.env.HEARTFLOW_ENGINE_PATH (line 55), HEARTFLOW_FULL_PATH (line 82) and HEARTFLOW_INDEX_PATH (line 127), then calls require(c)/require(hc)/require(idxPath) (lines 65, 93, 129). Any actor able to influence these variables of the harness process can make the plugin load arbitrary JavaScript that runs with full in-process privileges (filesystem, network, other plugins' data, harness APIs) at plugin start. No path containment, signature check or allowlist is applied.

  • mediumDecision logic is an unaudited vendored engine that gates user messages and tool callslib/index.js:54

    package.json ships "vendor" in files, and the plugin unconditionally require()s vendor/heartflow/src/gate.js, vendor/heartflow/src/core/heartflow.js and vendor/heartflow/src/index.js, then runs new HeartFlow({ dataDir: process.env.HEARTFLOW_DATA_DIR }) and hf.start(). That code decides whether agent/pre-step returns { kind: 'reject' } and whether tools/pre-execute returns { kind: 'deny' }, i.e. it can drop user turns and break arbitrary tool calls, yet its source is not part of this review. The optional dependency @yun520-1/heartflow ^6.5.9 is likewise a floating, unreviewed fallback.

  • lowRoute whitelist is silently skipped when the route table is unavailablelib/index.js:323

    callRoute() only enforces the subsystem/method allowlist inside `if (routeTable)`. routeTable stays null when engineMode is gate-only or when hf.routes() throws (line 147 sets routeTable = null), in which case coordinateRoute passes the raw model-supplied `subsystem.method` string to engine.dispatch (line 332). The format regex permits names such as `__proto__.constructor`, which also reaches `routeTable[sub].includes` and throws an uncaught TypeError. Impact is limited to whatever the local engine's dispatch exposes, but the defensive check is not guaranteed.

  • lowBlocked user input is silently rejected with no reason or feedbacklib/index.js

    In the agent/pre-step hook, when the rule engine returns gate.action 'block' for a user-role message, the plugin returns { kind: 'reject' } with no reason surfaced to the model or user. A false positive in a purely rule-based 47-dimension engine therefore drops the user's turn silently; combined with the unvalidated vendor engine this is a real availability and correctness risk for the harness.

Thin wrapper around an unaudited vendored rule engine; loads modules from env-var paths and can silently reject user turns and deny tool calls, but contains no shell, network or secret access itself.

Rule (2026-10-28): when a dynamic conclusion exists it is authoritative (it may raise or lower the level); the static scan tier (vet primary, dsh backstop) applies only when there is none (not queued / audit failed / withdrawn). The audit never writes the exemption list (exemptions are manual only); a wrong conclusion is withdrawn by human review and the tier falls back to the static scan tier.

Disclaimer: the static scan and the dynamic security audit are both automated analysis, not a security guarantee. Always review what you install.

Activity

Last commit 2026-08-15 · activity: Inactive

• Repo created: 2026-08-15

• Stars: ★ 5 · Forks: 1

• Health: Inactive — no commit in 90+ days

Source

GitHub: github.com/yun520-1/deepseek-heartflow

Frequently asked questions

What is deepseek-heartflow?

deepseek-heartflow is a DeepSeek Harness (dsh) plugin listed on dsh.so — an independent community registry that indexes public source repositories and publishes automated security-scan and install-verification results for each entry.

Is dsh.so or this plugin page official?

dsh.so is an independent community registry and is not affiliated with, endorsed by, or sponsored by DeepSeek AI.

How do I install deepseek-heartflow?

Run dsh plugin --profile web add @yun520-1/deepseek-heartflow@0.6.8 in a DeepSeek Harness (dsh) environment. That exact command passed a real install inside an isolated sandbox (L4); the web smoke test (L5) has not passed yet.

How does the security scan relate to a manual audit?

Both layers are automated, not a manual audit. The static scan is heuristic analysis of the repository source, so it can produce false positives and miss context. The model-driven dynamic security audit only covers plugins static-flagged at warn or above, never executes plugin code, and its conclusion is authoritative when there is one (it may raise or lower the static tier); exemptions stay manual. Neither layer is an endorsement: review the repository and the permissions it asks for before installing, together with the verification level and health signals.

How fresh is the data on this page?

The data on this page is as of 2026-10-24 (UTC) — the most recent valid timestamp among the registry refresh, install verification, security scan and dynamic audit. Build time is never used as a data date.

Was this page helpful?