- Canal 1024 store:
npm i -g dsh1024uma vez, depoisdsh1024 plugin --profile web add dsh-research-report(conta para o ranking de instalações do deepseek1024.com).
Um motor de relatórios de pesquisa verificáveis para DeepSeek Harness.
Cada afirmação (claim) fica vinculada a snapshots de evidência imutáveis, é verificada byte a byte e é selada num relatório versionado cujo hash de manifesto qualquer pessoa pode recomputar.
English · 简体中文 · Español · Português · हिन्दी
dsh plugin --profile <name> add dsh-research-report📖 Base de conhecimento do ecossistema — dados medidos, não marketing: guia de desenvolvimento · dados de seleção · critérios de manutenção.
dsh plugin --profile demo add dsh-research-report # instalar
dsh plugin --profile demo remove dsh-research-report # desinstalarVerifica que a linha monta: dsh --profile demo --dump-config | grep dsh-research-report.
Este plugin faz parte da família de plugins DSH (mais de 40, todos Apache-2.0). Se for útil, deixe uma estrela: não desbloqueia nada, mas ajuda a próxima pessoa a encontrá-lo.
English: part of a 95 plugin family for DeepSeek Harness. If it is useful, a star helps the next person find it — nothing is gated behind it.
Um motor de relatórios de pesquisa verificáveis para DeepSeek Harness.
Cada afirmação (claim) fica vinculada a snapshots de evidência imutáveis, é verificada byte a byte e é selada num relatório versionado cujo hash de manifesto qualquer pessoa pode recomputar.
Visão geral do fluxo: pergunta → fontes seladas → relatório. Os exemplos abaixo usam a superfície real de comandos.
A mesma execução, animada.
- DeepSeek Harness
dsh-v0.2.1-alpha.1(verificado em 2026-09-25). Linha npm dev/test0.1.7-rc.2; peers>=0.1.6-0 <0.2.0 || >=0.1.7-0 <0.2.0. A matriz compat fixa as quatro linhas peer declaradas. Nesta linha o terceiro parâmetro deSession.appendé umSurfaceIntentapenas para tipos de superfície, então os eventosresearch-report/*continuam sem ser gravados no log de sessão: os diários do ledger são a fonte durável e o espelho de auditoria ativa quando o host conhece o vocabulário (o cadeado de regressão emtest/events-gate.spec.tsfixa isso). 0.1.5-alpha.1 (adaptado em 2026-09-09): o envelope de sessão mantém seu campo ignorable apenas para compatibilidade de leitura de logs armazenados - o Session.append ainda não consegue estampá-lo, então o comportamento da porta não muda. Verificado em 2026-09-11 contra os tipos publicados 0.1.5-rc.2 (cadeia completa de portas local); o workflow compat fixa ambas as linhas peer declaradas. - Node
^22.19.0 || >=24.0.0, apenas ESM ("type": "module"). - Dependências peer:
@deepseek-ai/cordis ^4.0.2,@deepseek-ai/schemastery ^3.18.2, e@deepseek-ai/dsh-session,@deepseek-ai/dsh-tools,@deepseek-ai/dsh-system-prompt,@deepseek-ai/dsh-web,@deepseek-ai/dsh-jobsem>=0.1.6-0 <0.2.0 || >=0.1.7-0 <0.2.0. - Irmãos opcionais (nunca obrigatórios): providers de
ctx.webpara captura de URL/coleta,ctx.jobspara montagem em segundo plano,ctx.dataQuality(dsh-data-quality) para verificação de citações em datasets.
- Livro-razão de evidência — armazenamento de snapshots endereçado por conteúdo (
<ledgerRoot>/objects/<sha256>+ diários JSONL). O mesmo conteúdo é guardado exatamente uma vez; snapshots são imutáveis; cada leitura recomputa o hash, de modo que adulteração ou remoção é detetada em vez de confiada. - Vínculo claim ↔ evidência — claims registam-se com os ids de evidência em que se apoiam; o livro guarda o vínculo e cada veredito de verificação (o mais recente vence).
- Verificação ao nível do byte — cada número e cada trecho entre aspas de um claim tem de ser localizável literalmente nos snapshots vinculados. Sem evidência vinculada, ou sem literal verificável, o claim marca-se
unverified; evidência vinculada que não consegue confirmar nem desmentir os literais citados marca-oinsufficient; um rótulo cujo valor difere no snapshot (estando o valor citado ausente) marca-o comodisproven; snapshots adulterados/ausentes marcam-nocontradicted. Sem semântica, sem embeddings — apenas verificações de bytes auditáveis. - Ponte numérica opcional — quando um claim cita um dataset estruturado do workspace (CSV/JSON) e o
dsh-data-qualityestá montado, as citações são verificadas com tolerâncias através do seu contrato congeladoverifyCitations; uma discrepância do dataset desmente (disproves) o claim. - Evidência DOI (sem rede) — origens DOI são validadas deterministicamente (estrutura
10.xxxx/xxxx, lista branca de prefixos e conjunto de caracteres DOI); DOIs inválidos falham ruidosamente. Metadados opcionais de revista/ano são aceites, erequireJournalMetadatasó restringe a evidência DOI académica quando ativado. - Relatórios selados versionados —
<reportRoot>/<slug(topic)>/<YYYYMMDD-HHmmss>/report.md+manifest.json+verification.jsonl+disconfirmation.jsonl; o hash de selo é o SHA-256 do manifesto, que por sua vez carrega o hash do relatório, os hashes de toda a evidência e o hash de cada diário de auditoria. - Reauditoria pré-entrega e interceção do selo — antes de selar, cada claim vinculado é re-verificado offline e registado em
verification.jsonl; drift de veredito, evidência vinculada adulterada/ausente, ou falha de serialização do diário bloqueiam o selo (falha ruidosamente, sem tunable). - Livro de falsificação — cada claim contradito ou desmentido é registado em
disconfirmation.jsonl(claim + referências de evidência + motivo) e listado no apêndiceregistro de falsificaçãodo relatório. - Conhecimento negativo — um claim desmentido é recordado pelo seu hash de conteúdo (
disproofs.jsonl); o mesmo texto re-reportado contra evidência inalterada é forçado de volta adisprovene só se re-verifica quando a evidência muda. - Ciclo de verificação de só-leitura — após selar, o recurso determinista
verifySealedReport(sem rede, sem modelo) recomputa o selo e os hashes de auditoria e re-verifica cada claim, escrevendo a secção de verificação de máquina emverifier-note.md; comctx.jobsmontado também é lançado um trabalho de verificação de só-leitura (a revisão do modelo é uma melhoria, nunca uma substituição). - Evidência ancorada a sessão —
evidence_addaceita umsessionRefopcional (sessionId+eventRange, validado ruidosamente); a âncora é guardada e registada no Apêndice B, no manifesto e emverification.jsonl. A evidência ancorada a sessão verifica-se honestamente comounverified(a evidência ancorada à sessão requer uma verificação manual no registo da sessão). - Lacunas honestas — claims não verificados, insuficientes, contraditos ou desmentidos mantêm uma marca visível
[未核实]/[证据不足]/[与证据矛盾]/[已证伪]no corpo do relatório e são listados no Apêndice A. Nada passa em silêncio. - Sem ciclo de deep-research — a orquestração de recuperação é deliberadamente reutilizada:
ctx.webpara pesquisa/download,ctx.jobspara trabalhos longos. Planeamento e síntese ficam com o modelo (ou um plugin a montante).
dsh plugin --profile web add github:PerryLink/dsh-research-report# A partir de um profile de teste (fixa o commit; executa o build `prepare` autossuficiente)
dsh plugin --profile demo add "github:YOUR_ORG/dsh-research-report#<sha>"
# O primeiro add acrescenta uma entrada allowBuilds para dsh-research-report no pnpm-workspace.yaml do profile.dsh plugin --profile demo add dsh-research-reportAmbos os canais instalam a linha do bundle (ver cordis.patch.yml) na pilha dsh.profile.bundles do profile e entram em vigor após reiniciar.
Depois, numa sessão:
evidence_add({ origin: "docs/market.md", title: "Market snapshot" }) # → ev-1a2b3c4d5e6f
research_report({ topic: "示例行业概览", sections: [...], claims: [...], evidenceRefs: ["ev-1a2b…"] })
ledger_query({ claimId: "c1" }) # vínculos + veredito
São os pontos de entrada reais; instale e chame um.
Comando
research_report({
topic: "示例行业概览",
sections: [{ heading: "市场规模", paragraphs: [{ text: "2025 年全球示例行业市场规模为 1,280 亿元。", claimIds: ["c1"] }] }],
claims: [{ id: "c1", text: "市场规模为 1,280 亿元", evidenceIds: ["ev-5dc0a84d0e48"] }],
evidenceRefs: ["ev-5dc0a84d0e48", "ev-c6cf024e0916", "ev-61f8f4533cb7"]
})Saída
report sealed: /tmp/rr-test-4U2mlF/reports/示例行业概览/20261019-124904
seal (sha256 of manifest.json): 5c85c97597096ced281ca191d7abaaf7434f18b397d35ac81c31aa364a3b12f9
claims: 1 verified / 0 unverified / 0 contradicted / 0 insufficient / 0 disproven (of 1); evidence bound: 3
Observado em README.md:112-118,150; test/index.spec.ts:166-177; src/tools/research-report.ts:170-175
Entrada
{"topic":"probe","sections":[{"heading":"Growth","paragraphs":[{"text":"Growth was 42%.","claimIds":["c1"]}]}],"claims":[{"id":"c1","text":"Growth was 42%.","evidenceIds":[]}]}
Saída
edge-case (no throw): isError=false; kind=sealed; verdicts[0]={"claimId":"c1","status":"unverified","note":"claim binds no evidence snapshot"}; counts={"verified":0,"unverified":1,"contradicted":0,"insufficient":0,"disproven":0}; evidenceCount=0; report.md marker=Growth was 42%. [未核实]
Observado em plugins/dsh-research-report/src/verify.ts:173-175 (unverified verdict); plugins/dsh-research-report/src/assemble.ts:209-220 (visible mark); plugins/dsh-research-report/README.md:87 (honest gaps); exercised through plugins/dsh-research-report/test/harness.ts
research_reportledger_query
Todos os ajustes são campos Config de Schemastery; valores inválidos falham ruidosamente no carregamento do profile. Raízes relativas resolvem contra o diretório de trabalho do harness (o workspace).
| Key | Default | Description |
|---|---|---|
enabled |
true |
Interruptor mestre; false não monta nada. |
ledgerRoot |
.research-ledger |
Diretório do livro de evidência (objetos + diários JSONL). |
reportRoot |
research-reports |
Raiz dos relatórios selados (versionados por tópico e timestamp). |
workspaceRoot |
(diretório de trabalho da sessão do host) | Raiz para evidência por caminho; padrão: diretório da sessão e depois o cwd do harness. |
maxEvidenceBytes |
2097152 |
Teto rígido de bytes UTF-8 por snapshot de evidência. |
maxEvidencePerReport |
200 |
Teto rígido de evidências vinculadas a um relatório. |
fetchTimeoutMs |
20000 |
Prazo (ms) de cada ctx.web fetch durante a captura. |
requireJournalMetadata |
false |
Quando true, a evidência de tipo DOI tem de trazer nome de revista e ano de publicação ao registar (falha ruidosamente caso contrário). |
evidence_add({ origin, content?, title? })— regista um snapshot de evidência. Comcontent, o texto é guardado literal; sem ele, uma origem URL é descarregada viactx.webe um caminho relativo do workspace é lido do disco (leituras nunca escapam do workspace). Devolve o id da evidência e o hash SHA-256.research_report({ topic, title?, sections, claims, evidenceRefs, gather?, depth?, background? })— monta e sela um relatório: valida (referências a claims não registados são rejeitadas ruidosamente), verifica cada claim, renderizareport.mdcom marcas visíveis, escrevemanifest.jsone devolve o hash de selo.gather: trueexecuta UMA ronda de pesquisa sobrectx.webe devolve evidência candidata capturada mais uma lista explícita de lacunas — nunca monta automaticamente.background: truedevolve{ kind: 'background', jobId }sobrectx.jobs.ledger_query({ claimId? | evidenceId? })— consultas só de leitura de vínculos/vereditos; a evidência é re-hasheada na leitura, por isso um snapshot adulterado ou em falta é reportado explicitamente. Sem id, devolve um resumo do livro.ctx.researchReport.assemble(request)— a superfície de serviço congelada para plugins irmãos (versrc/service.ts; protegida byte a byte porscripts/verify-frozen-contract.mjs).
dsh-research-report consome apenas seams públicos: ctx.tools, ctx.systemPrompt, e opcionalmente ctx.web / ctx.jobs / ctx.dataQuality (consultados no momento da chamada, nunca injetados). Escreve apenas dentro das raízes configuradas de livro e relatórios (ambas por omissão diretórios locais do workspace), lê ficheiros do workspace apenas dentro do workspace, e acede à rede exclusivamente através do seam web do harness — nunca um fetch direto. Snapshots de evidência são imutáveis e endereçados por conteúdo; registos de claims são imutáveis; vereditos são apenas de anexação.
- Evidência de adulteração por construção — cada leitura de snapshot recomputa o SHA-256 contra o índice; uma discrepância verifica os claims vinculados como
contradictede oledger_queryreportaintegrity: tampered/missing. - Confinamento ao workspace — leituras locais de evidência resolvem contra a raiz do workspace e recusam escapes (ambos os lados passam por
path.resolveantes de comparar). - Configuração que falha ruidosamente — limites inválidos lançam no mount; referências a claims não registados, ids de evidência desconhecidos e conflitos id/conteúdo lançam na montagem.
- Sem gestão de credenciais, sem rede oculta — a captura de URLs passa por
ctx.web(seleção de provider, taxonomia de erros e qualquer política SSRF ficam nos providers web do deployment). - Registos reversíveis — cada contribuição passa por
ctx.effect()/register(), logo desinstalação e hot reload são limpos.
- Ao nível do byte, não semântico — a verificação incorporada localiza literais numéricos/entre aspas verbatim; claims parafraseados sem literal verificável ficam
unverified, e um claim verdadeiro cujo número está ausente enquanto o seu rótulo aparece com outro valor ficacontradicted. É uma escolha deliberada da v1 (auditável acima de inteligente). - Eventos de sessão adaptativos — o plugin declara os eventos de sessão tipados
research-report/evidence,research-report/verifyeresearch-report/seal, mas oSession.appendde 0.1.5-alpha.1 continua sem opçãoignorablenem superficie de registo de eventos para plugins, por isso os appends só ativam quando o build do host conhece os tipos (caso contrário a camada de persistência recusaria o log no restore). Os diários do livro são sempre a fonte durável da verdade. - Profiles por omissão não montam provider de fetch — o
dsh-basedistribuído monta apenas pesquisa, por isso a captura de URLs falha ruidosamente (WEB_UNAVAILABLE/WEB_PROVIDER_UNAVAILABLE) até configurar um provider de fetch; ogatherbaseado em pesquisa lista as fontes não capturadas na lista de lacunas. - Âmbito de um só workspace — as raízes de livro e relatórios resolvem contra o diretório de trabalho do harness no mount; deployments multi-workspace devem configurar raízes absolutas por profile.
O binário independente dsh-research-verify (empacotado como lib/cli.js, sem imports de @deepseek-ai) audita qualquer diretório de relatório selado sem montar o plugin:
dsh-research-verify --report <dir> [--seal <sha256>] [--ledger <dir>] [--format json|sarif]--report <dir>— diretório selado (manifest.json+report.md+ diários de auditoria).--seal <sha256>— hash de selo esperado para comparar com o hash do manifest recalculado; omitido = apenas o valor é informado, sem comparação.--ledger <dir>— raiz do ledger de evidências (objects/<sha256>+index.jsonl) para re-verificar claims byte a byte; omitido = os re-checks de claims são omitidos honestamente.--format—json(padrão) ousarif(SARIF 2.1.0).
Recalcula o hash de selo, o hash de report.md e os hashes dos diários, re-executa a verificação byte-level + integridade por claim, e sai com código não nulo se alguma checagem falhar. verifySealedReport / buildVerificationReport / renderSarif / renderVerificationJson são exportados do pacote para uso como biblioteca.
pnpm install
pnpm run typecheck && pnpm run typecheck:ci
pnpm test
pnpm run build
pnpm run verify:self-contained && pnpm run verify:artifacts
node scripts/check-readme-sync.mjs
node scripts/verify-frozen-contract.mjs
pnpm packtypecheckresolve@deepseek-ai/*através dos peers 0.1.7-rc.2 instalados;typecheck:cidesativaskipLibChecke ativaverbatimModuleSyntaxcontra os tipos publicados. Ambos têm de ficar verdes.- Os testes usam os
Context/Session/ToolRuntime/LocalJobRegistry/WebRuntimereais dos peers 0.1.7-rc.2; apenas os backends de rede são providers scriptados registados através dos registos reais dectx.web. - Release:
node scripts/release.mjs <x.y.z>(sobe versão, carimba CHANGELOG, re-executa a gate, commita + etiqueta; nunca faz push).
dsh, dsh-plugin, deepseek-harness, cordis, research, evidence-ledger, verifiable-report, audit, citation-verification
- PerryLink — autor original e mantenedor: arquitetura do plugin, ledger de evidências, verificação em nível de byte, relatórios selados, documentação em cinco idiomas e automação de CI/lançamento.
Este projeto faz parte da família de plugins do DeepSeek Harness da PerryLink. O registro fica recolhido abaixo para que cada README mantenha uma primeira tela curta; expanda para ver cada linha e seu status.
Expandir todos os plugins
Apache-2.0 — ver LICENSE.
Todos os plugins PerryLink podem ser explorados no mercado integrado do DSH Desktop: Market → Sources → add source → colar https://perrylink-dsh-catalog.perrylink.workers.dev/catalog-source.json → selecionar. A instalação continua passando pela verificação de identidade npm do mercado e pela sua confirmação.