Skip to content

Latest commit

 

History

History
361 lines (276 loc) · 28.1 KB

README-pt.md

File metadata and controls

361 lines (276 loc) · 28.1 KB

📑 dsh-research-report

  • Canal 1024 store: npm i -g dsh1024 uma vez, depois dsh1024 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.

License Gitee DSH plugin dsh-doctor DSH Market Node CI Version npm version npm downloads dshfind

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.

Install & uninstall

dsh plugin --profile demo add dsh-research-report       # instalar
dsh plugin --profile demo remove dsh-research-report    # desinstalar

Verifica 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.

What is dsh-research-report?

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.

Diagrama de fluxo de dsh-research-report: pergunta → fontes seladas → relatório.

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.

Compatibility

  • DeepSeek Harness dsh-v0.2.1-alpha.1 (verificado em 2026-09-25). Linha npm dev/test 0.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 de Session.append é um SurfaceIntent apenas para tipos de superfície, então os eventos research-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 em test/events-gate.spec.ts fixa 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-jobs em >=0.1.6-0 <0.2.0 || >=0.1.7-0 <0.2.0.
  • Irmãos opcionais (nunca obrigatórios): providers de ctx.web para captura de URL/coleta, ctx.jobs para montagem em segundo plano, ctx.dataQuality (dsh-data-quality) para verificação de citações em datasets.

What you get

  • 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-o insufficient; um rótulo cujo valor difere no snapshot (estando o valor citado ausente) marca-o como disproven; snapshots adulterados/ausentes marcam-no contradicted. 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-quality está montado, as citações são verificadas com tolerâncias através do seu contrato congelado verifyCitations; 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, e requireJournalMetadata só 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êndice registro de falsificação do 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 a disproven e 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 em verifier-note.md; com ctx.jobs montado 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_add aceita um sessionRef opcional (sessionId + eventRange, validado ruidosamente); a âncora é guardada e registada no Apêndice B, no manifesto e em verification.jsonl. A evidência ancorada a sessão verifica-se honestamente como unverified (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.web para pesquisa/download, ctx.jobs para trabalhos longos. Planeamento e síntese ficam com o modelo (ou um plugin a montante).

Quick start

dsh plugin --profile web add github:PerryLink/dsh-research-report

Canal git

# 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.

Canal npm

dsh plugin --profile demo add dsh-research-report

Ambos 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

Exemplos

São os pontos de entrada reais; instale e chame um.

Exemplo detalhado

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

Ramo de falha

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

Exemplos breves

  • research_report
  • ledger_query

Configuration

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).

Tools & surfaces

  • evidence_add({ origin, content?, title? }) — regista um snapshot de evidência. Com content, o texto é guardado literal; sem ele, uma origem URL é descarregada via ctx.web e 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, renderiza report.md com marcas visíveis, escreve manifest.json e devolve o hash de selo. gather: true executa UMA ronda de pesquisa sobre ctx.web e devolve evidência candidata capturada mais uma lista explícita de lacunas — nunca monta automaticamente. background: true devolve { kind: 'background', jobId } sobre ctx.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 (ver src/service.ts; protegida byte a byte por scripts/verify-frozen-contract.mjs).

Permissions & data

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.

Security boundaries

  • 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 contradicted e o ledger_query reporta integrity: 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.resolve antes 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.

Known limitations

  • 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 fica contradicted. É 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/verify e research-report/seal, mas o Session.append de 0.1.5-alpha.1 continua sem opção ignorable nem 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-base distribuído monta apenas pesquisa, por isso a captura de URLs falha ruidosamente (WEB_UNAVAILABLE/WEB_PROVIDER_UNAVAILABLE) até configurar um provider de fetch; o gather baseado 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.

Verifier CLI

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) ou sarif (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.

Development

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 pack
  • typecheck resolve @deepseek-ai/* através dos peers 0.1.7-rc.2 instalados; typecheck:ci desativa skipLibCheck e ativa verbatimModuleSyntax contra os tipos publicados. Ambos têm de ficar verdes.
  • Os testes usam os Context/Session/ToolRuntime/LocalJobRegistry/WebRuntime reais dos peers 0.1.7-rc.2; apenas os backends de rede são providers scriptados registados através dos registos reais de ctx.web.
  • Release: node scripts/release.mjs <x.y.z> (sobe versão, carimba CHANGELOG, re-executa a gate, commita + etiqueta; nunca faz push).

Topics

dsh, dsh-plugin, deepseek-harness, cordis, research, evidence-ledger, verifiable-report, audit, citation-verification

Contributors

  • 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.

PerryLink DSH Plugin Family

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
Plugin Status
dsh-aqua-input-check
dsh-archive-check
dsh-auto-review
dsh-autotier
dsh-bid-ca-precheck
dsh-bid-qual-check
dsh-cert-mcp
dsh-checkpoint-rewind
dsh-click
dsh-composer-history
dsh-contract-stance
dsh-customs-doc-check
dsh-data-quality
dsh-demurrage-ledger
dsh-doublecheck
dsh-drill-script-check
dsh-eia-guide-check
dsh-emergency-plan
dsh-essay-rubric-check
dsh-evidence-check
dsh-export-ctl-check
dsh-fast
dsh-fmea-table-check
dsh-forecast-penalty
dsh-fund-research
dsh-github
dsh-gongwen-flow-check
dsh-gongwen-word-check
dsh-guard-plan-qc
dsh-hazchem-check
dsh-hazplan-check
dsh-hidden-risk-map
dsh-hs-classify
dsh-icd-rule-check
dsh-industry-research
dsh-lawcite-adapter
dsh-laya
dsh-lc-doc-check
dsh-learning-gap-check
dsh-library
dsh-local-ai
dsh-lsp-actions
dsh-mask
dsh-mcp-panel
dsh-medrec-qc
dsh-memento
dsh-nsfc-form-check
dsh-nurse-record-check
dsh-observe
dsh-origin-rvc-check
dsh-ota-review-check
dsh-output-styles
dsh-paper-doc-adapter
dsh-permission-rules
dsh-permit-report-check
dsh-pipeline-check
dsh-pleading-draft
dsh-plugin-doctor
dsh-plugin-guide
dsh-plugin-kit
dsh-plugin-upgrade
dsh-policy-brief-draft
dsh-power-loss-split
dsh-power-ticket-check
dsh-ppap-check
dsh-protest-deadline
dsh-railway-window
dsh-repair-order-qc
dsh-research-report
dsh-review-reply-check
dsh-rulefile-check
dsh-safety-brief-check
dsh-score
dsh-session-sync
dsh-site-log-check
dsh-skill-pack-security
dsh-soe-decision-check
dsh-soilwater-check
dsh-sop-sync-check
dsh-spc-gbt-adapter
dsh-talk
dsh-tender-extract
dsh-tender-matrix
dsh-test-drive
dsh-ticktick
dsh-translate
dsh-warranty-calc
dsh-budget 🧊 CONGELADO — ver o README do repositório
dsh-claude-move 🧊 CONGELADO — ver o README do repositório
dsh-defend 🧊 CONGELADO — ver o README do repositório
dsh-draw 🧊 CONGELADO — ver o README do repositório
dsh-reach 🧊 CONGELADO — ver o README do repositório
dsh-background-agents 🚫 RETIRADO — ver o README do repositório
dsh-session-pin 🚫 RETIRADO — ver o README do repositório
dsh-team-rooms 🚫 RETIRADO — ver o README do repositório

License

Apache-2.0 — ver LICENSE.

Instalar a partir do mercado do DSH Desktop

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.