Other formats agents might prefer:
markdownjsonllms.txt

Agent? You probably want markdown or json, or Pod over MCP.

Reported issues for Vouch

Pod holds 15 of 15 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to Vouch.

Most discussed

fix(list): kb.list_pages / vouch pages include archived pages

What happened

kb.list_pages (MCP), kb.list_pages (JSONL), and vouch pages all pass store.list_pages() through filter_pages with no PageStatus.ARCHIVED filter. Archived pages remain in the agent-facing live listing. MCP/CLI payloads also omit status, so an archived page is indistinguishable from a live one.

This is the same live-set leak class as wiki/neighbors/compile/session-split (#695–#713), on the listing surface those fixes did not cover.

Expected

Listing surfaces ex

Read the thread · 2026-07-31 · closed · outside contributor · 1 comment

feat(config): typed Config model + validation for .vouch/config.yaml

What you're trying to do

.vouch/config.yaml is currently parsed as an untyped dict (yaml.safe_load) and read defensively at each call site — e.g. storage.py writes the starter config as a literal dict, and proposals.py re-reads it with nested .get() + isinstance guards and a silent except Exception fallback to {} for review.approver_role. As more features grow config keys (retrieval.backends, retrieval.reflex, mcp.publish_skills, page_kinds, …) this pattern sprea

Read the thread · 2026-06-17 · closed · outside contributor · 0 comments

Graph-aware retrieval: kb.neighbors and --expand-graph for context packs

What you're trying to do

When I'm working with a vouch KB that has entities, relations, and linked claims/pages, I want retrieval to follow the graph — not just text similarity — because related knowledge often lives one hop away from a search hit.

Example: An agent runs vouch context "auth service". Search returns a claim about JWT, but misses:

  • the entity auth-service linked via references
  • a depends_on decision on the same subsystem
  • the page that includes_claim for that fact

Today,

Read the thread · 2026-06-09 · closed · outside contributor · 0 comments

critical: Agent transport allows cross-agent approval

Summary

The review-gate docs say agents do not have an approve tool, but the JSONL/MCP tool surface exposes kb.approve to agents. The self-approval guard blocks the same VOUCH_AGENT, but a second agent identity can approve another agent’s proposal through vouch serve --transport jsonl, landing durable claims without any human CLI review.

Reproduction Steps

  1. Initialize a KB and add a source.
  2. Propose a claim through JSONL as VOUCH_AGENT=alice.
  3. Try approving as alice to co

Read the thread · 2026-06-05 · closed · outside contributor · 1 comment

[Bug] Bundle import can overwrite the audit log

Summary

vouch import-apply --on-conflict overwrite accepts a bundle containing audit.log.jsonl and overwrites the KB’s append-only audit log. The bundle format documents safety flags for “no proposed/, no state.db, no audit.log”, but import does not enforce those flags or block forbidden paths.

Reproduction Steps

  1. Create a fresh KB:
    tmp=$(mktemp -d)
    cd "$tmp"
    vouch init
    
  2. Create a bundle whose manifest includes audit.log.jsonl.
  3. Run:
    v
    

Read the thread · 2026-06-05 · closed · outside contributor · 1 comment

feat: review-gate policy engine — conditional auto-approve, block, and escalation rules [VEP]

What you're trying to do

When operating in a multi-agent or team environment, a single approver_role: human flag is far too coarse. Today every proposal — whether it is a trivial fact Claim filed by a well-known trusted agent or a new Entity proposed by an unknown actor — goes into the same pending queue and waits for a human to act on it.

In practice, three patterns come up constantly:

  1. Trusted-agent fast-path. A well-configured agent (e.g. claude-code) files a fact Cla

Read the thread · 2026-06-04 · closed · external user · 0 comments

feat: HTTP transport with bearer-token auth and SSE streaming for vouch serve

What you're trying to do

Today vouch's two transports — MCP over stdio and JSONL over stdin/stdout — require the agent and the KB server to run in the same process or be pipe-connected. This works well on a single developer's machine but breaks down the moment you want to:

  1. Share a single reviewed KB across multiple machines (e.g. a team CI runner proposes claims; a human on their laptop reviews and approves them via CLI — currently impossible without committing proposals to git, whic

Read the thread · 2026-06-03 · closed · external user · 0 comments

bug: kb.context returns archived/superseded claims; lifecycle mutations never re-index FTS5 status

What happened

kb.context returns claims that have been archived, superseded, contested, or redacted as if they were live — agents receive retracted knowledge in their context pack. Two compounding bugs combine to produce this:

Bug A — build_context_pack has no status filter. src/vouch/context.py:75-101 walks the hits from _retrieve and appends every match to the context pack. There is no check on claim.status. Once a claim is indexed, it stays in retrieval forever, r

Read the thread · 2026-05-25 · closed · outside contributor · 0 comments

Most recent

expose health.fsck() as kb.fsck on MCP/JSONL/capabilities (roadmap 1.5)

What you're trying to do

ROADMAP.md's 1.5 milestone: "vouch fsck — deeper consistency checks than doctor." That check already exists (health.fsck(), wired as the vouch fsck CLI command) — but it's the one diagnostic sweep with no agent-facing path: no MCP tool, no JSONL handler, not in capabilities.METHODS. An agent can call kb.lint and kb.doctor but has no way to run the deepest check (kb.fsck's own checks: orphaned embeddings, dangling supersede/contradict chains, decided-p

Read the thread · 2026-07-31 · open · outside contributor · 0 comments

kb.neighbors leaks edges pointing to excluded (superseded/archived/redacted/missing) nodes

What happened

find_neighbors() in src/vouch/graph.py records an edge into the response before checking whether the edge's other endpoint passes the same retrievability/existence gate that decides node inclusion:

# src/vouch/graph.py (before fix)
for edge in _edges_from_node(store, current, rel_types=rel_filter):
    other = edge.target if edge.source == current else edge.source
    ekey = (edge.source, edge.target, edge.relation)
    if ekey not in seen_edges:
        seen_edg

[Read the thread](https://github.com/vouchdev/vouch/issues/716) · 2026-07-31 · closed · outside contributor · 0 comments

### security: kb.detect_themes leaks claim and session ids the viewer cannot retrieve

## what

`themes.detect_themes` scans `store.list_claims()` and filters on status
(`archived` / `superseded` / `redacted`) and `approved_by`, but never on
`ArtifactScope`. Every other read surface — `kb.search`, `kb.context`,
`kb.recall`, the salience sidebar, `kb.explain_ranking` — passes its claims
through `scoping.is_visible` first. themes does not.

A `ThemeCluster` carries `claim_ids` and `session_ids`, so an unfiltered scan
hands a caller the ids of private or cross-project claims it canno

[Read the thread](https://github.com/vouchdev/vouch/issues/657) · 2026-07-30 · closed · outside contributor · 0 comments

### feat(server): cursor pagination for `kb.list_*` methods

**What you're trying to do**

The read-side `kb.list_*` methods (`kb.list_pages`, `kb.list_claims`,
`kb.list_entities`, `kb.list_relations`, `kb.list_sources`, `kb.list_pending`)
return the *entire* collection in one shot. Under the hood `storage.list_*`
reads and parses every YAML file in the directory, and the JSONL/MCP handlers
hand back the full list with no `limit`/`offset`/`cursor`. On a KB with tens of
thousands of claims this is unbounded memory on the server and an unbounded
payload ove

[Read the thread](https://github.com/vouchdev/vouch/issues/245) · 2026-06-17 · closed · outside contributor · 0 comments

### validation gap: artifact ids accept path-traversal strings and reach filesystem paths unsanitised in storage operations

## Problem

Every non-Source artifact model — `Claim`, `Page`, `Entity`, `Relation`, `Evidence`, `Session`, `Proposal` — declares `id: str` with no validator. `Source.id` is locked to a hex sha256 by `_id_is_hex_sha256` (`src/vouch/models.py:148-153`); nothing similar exists for the others (`src/vouch/models.py:179, 225, 238, 254, 163, 290, 318` — all bare `id: str`).

The storage layer turns those ids straight into filesystem paths with no containment check:

```python
# src/vouch/storage.py:22

[Read the thread](https://github.com/vouchdev/vouch/issues/149) · 2026-06-02 · closed · outside contributor · 0 comments

### feat: Add `--json` output to `vouch pending`

## What you're trying to do

When I’m reviewing proposals in a multi-agent repo, I want to inspect pending proposals in a machine-readable format so I can group them by agent, count noisy proposal sources, or wire the review queue into shell scripts and CI checks.

The docs already suggest this workflow:

```bash
vouch pending --json | jq -r '.[] | "\(.proposed_by)\t\(.id)"' | sort | uniq -c

but vouch pending --json does not appear to exist yet.

What you've tried

vouch status --json give

Read the thread · 2026-05-26 · closed · outside contributor · 0 comments

fix(cli): approve and reject commands don't catch ProposalError — raw traceback

The CLI approve and reject commands catch (ArtifactNotFoundError, ValueError) but proposals.approve() and proposals.reject() raise ProposalError(RuntimeError) for validation failures. This causes users to see raw Python tracebacks instead of clean error messages.

Bug

  • File: src/vouch/cli.py:192-196 (approve) and src/vouch/cli.py:204-209 (reject)
  • Buggy code (approve):
@cli.command()
@click.argument("proposal_id")
@click.option("--reason", default=None)
de

[Read the thread](https://github.com/vouchdev/vouch/issues/29) · 2026-05-19 · closed · external user · 0 comments

The remaining reports are on [the project's issue tracker](https://github.com/vouchdev/vouch/issues).