[Submission] dsh-jev-tools@0.1.5

[HorusJiang]

Author Studio manifest

{
  "schema": "omdsh-workshop-submission/v2",
  "operation": "create-project",
  "project": {
    "id": "dsh-jev-tools",
    "displayName": "dsh-jev-tools",
    "summary": "Jev judgments inside DeepSeek Harness: prune oversized tool output, screen fetched pages for injected instructions, suggest which skill fits, and check claims before \"done\".",
    "kind": "extension",
    "category": "developer-tools",
    "tags": [
      "deepseek-harness",
      "dsh-plugin",
      "jev",
      "typesafe",
      "context",
      "guardrails"
    ],
    "repository": "https://github.com/HorusJiang/dsh-jev-tools",
    "path": null,
    "author": {
      "name": "HorusJiang",
      "url": "https://github.com/HorusJiang"
    },
    "license": "MIT",
    "media": {
      "cover": "docs/banner.png"
    }
  },
  "release": {
    "version": "0.1.5",
    "ref": "3808b4124e27346f2c8a94438db4eb9b44fb6b36",
    "updatedAt": "2026-09-21T01:16:18Z",
    "channel": "stable",
    "compatibility": "package.json#dsh.compatibility.dshReleases declares 0.1.6-alpha.2 compatible. No other DSH release has been tested; the plugin uses only documented Cordis services and events and no host internals.",
    "changelog": "Adds the dshWorkshop manifest declared in this submission. Behaviour is unchanged from 0.1.3: three automatic Jev judgments (prune oversized tool output, screen fetched pages for injected instructions, suggest a skill) plus the jev_ask and jev_gate tools, a judgment ledger that survives restarts, and the /jev-status command.",
    "capabilities": {
      "requiresFabric": false,
      "deepHook": false,
      "restartRequired": true
    },
    "profileBundle": null,
    "updateFrom": null
  },
  "management": {
    "method": "guided",
    "protocol": "harness-cordis",
    "label": "DeepSeek Harness Cordis bundle (published on npm)",
    "instructions": "A DeepSeek Harness Cordis plugin. The pinned commit declares dsh.bundle.patch -> cordis.patch.yml, which inserts one row mounting the host half and one Web settings section. Installation and enablement are performed by the harness's own plugin management, so no command is provided here. A TypeSafe API key is required before any judgment runs; with no key configured the plugin mounts, does nothing, and sends no request at all.",
    "source": null
  },
  "declarations": {
    "permissions": "Declared in package.json#dshWorkshop.permissions: network:outbound (HTTPS to api.typesafe.ai, and only once a key is configured); credentials:read (resolves TYPESAFE_API_KEY through the host credential store, never logged and never echoed back); storage:read, storage:write (the judgment ledger in the dsh_jev_tools storage domain under $DSH_HOME/storages); settings:read (resolved plugin configuration); session:append (advisory notices appended to tool results, and at most one skill suggestion per turn); skills:read (skill names and descriptions, used for that suggestion); tools:register (jev_ask, jev_gate); commands:register (/jev-status); ui:extend (the settings section registered in the plugins.bundle.config slot); filesystem:none (the plugin does not touch the filesystem itself). The package declares one lifecycle script, prepare, because lib/ is a build output that is not committed; registry installs never run it. No process is spawned, no shell command is executed, and nothing from judged content is evaluated as code.",
    "testing": "192 tests run through node --test via npm test (tsc build first, no test framework) covering pruning, injection screening, skill suggestion, the jev_ask and jev_gate tools, the ledger and its storage domain, the settings schema, and the bilingual documentation pairing. No API key and no network are required. Live API measurements are recorded in docs/s0-trigger-rate.md.",
    "trustedPublisherRequested": false,
    "installScriptsMustRemainDisabled": true
  },
  "packageManifest": {
    "schema": "omdsh-workshop-package/v1",
    "type": "plugin",
    "integration": {
      "protocol": "harness-cordis",
      "artifact": "cordis.patch.yml"
    },
    "install": {
      "mode": "guided",
      "adapter": "third-party",
      "failurePolicy": "manual",
      "touchesCurrentBeforeActivation": false
    },
    "lifecycle": {
      "activation": "restart-host",
      "dispose": "unknown"
    },
    "permissions": [
      "network:outbound",
      "credentials:read",
      "storage:read",
      "storage:write",
      "settings:read",
      "session:append",
      "skills:read",
      "tools:register",
      "commands:register",
      "ui:extend",
      "filesystem:none"
    ],
    "compatibility": {
      "dshVersions": [
        "0.1.6-alpha.2"
      ]
    },
    "capability": {
      "id": "jev-status",
      "kind": "command",
      "invocation": "/jev-status",
      "expected": "prints whether the plugin is enabled, whether an API key was resolved and from where, the judgment and skip counts for this session, and where the ledger is stored; it answers with no API key configured"
    },
    "evidence": {
      "install": "cordis.patch.yml",
      "failureIsolation": null,
      "hotReload": null,
      "remove": null
    }
  }
}

Submission boundary

• This request contains only public, immutable source coordinates and the generated structured manifest.
• Automated intake may create a pending-review PR, but cannot approve the project or grant Registry installation authority.

Confirmations

• The repository and pinned commit are public.
• Permissions, tests, compatibility, and external effects are declared from verifiable evidence.
• No credential, private path, or private data is included.

[github-actions]

自动化插件预检未通过，尚未创建待审核记录。请查看 本次检查，修正固定来源或清单后重新提交。

[HorusJiang]

The failure does not appear to be in the submitted manifest, so it may be worth a look on the Workshop side:

• npm run validate fails in scripts/check-public-site.mjs:135 — "verification inventory must cover every Catalog project, match exact Intake evidence, and grant no Registry admission". That is a repository self-check that runs before anything submission-specific, and the same run reports 0 formal Intake candidates.
• The scheduled discover workflow has also been failing on every run for at least a day (e.g. runs 35521929695, 35536930345 on 2026-09-20), which points at the same invariant rather than at this issue's payload.
• The submission side was checked locally against Workshop 928cb55: node scripts/intake.mjs validate submission.json prints submission accepted for pending review; no repository code was executed. The pinned commit 3808b4124e27346f2c8a94438db4eb9b44fb6b36 is public and readable, and its package.json#dshWorkshop is byte-identical to the packageManifest in the issue body above (harness-cordis with the third-party adapter, per the protocol mapping).

Nothing here is an argument against fixing the payload — happy to adjust anything that is actually wrong in it. I would just rather not churn it while the gate is red for an unrelated reason.

提交内容在 Workshop 当前 main（928cb55）上通过了 scripts/intake.mjs validate；这次失败的是仓库自检 check-public-site.mjs:135，定时 discover 也一直卡在同一个不变式上。