# Reported issues for dotrepo

Pod holds 12 of 12 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 [dotrepo](/mcp/dotrepo).

## Most discussed

### Add a trust/conflict inspection command or mode

## Summary
Add a human-facing way to inspect authority decisions, conflicts, and superseded records.

## Why
If query starts resolving competing claims, maintainers and reviewers need a clear way to understand why one record won.

## Scope
- Decide whether to extend `trust` or add a new command/subcommand.
- Show:
  - selected record
  - competing records
  - precedence reason
  - supersede status
  - trust/provenance notes
- Support machine-readable output.

## Acceptance criteria
- There is a 

[Read the thread](https://github.com/maxwellsantoro/dotrepo/issues/17) · 2026-03-09 · closed · 3 comments

### Add append-only claim event writer for reviewer transitions

## Summary
Add a CLI helper that appends validated claim events and keeps claim history append-only while updating the current claim state in `claim.toml`.

## Why
Reviewer workflow needs a disciplined way to move claims through submitted, in-review, accepted, rejected, withdrawn, disputed, and corrected states without hand-editing multiple files.

## Scope
- Add a CLI entry point for appending a new claim event.
- Derive the next event sequence number automatically.
- Validate allowed state tra

[Read the thread](https://github.com/maxwellsantoro/dotrepo/issues/51) · 2026-03-10 · closed · 2 comments

### Surface claim context in trust and query reports

## Summary
Surface claim context in trust and query reports when it materially explains current record visibility.

Part of #34.

## Why
RFC 0012 defines claim-aware visibility as an extension of the existing `selection` / `conflicts` model. Once read-only claim inspection exists, trust/query reports should expose relevant claim context without becoming full claim ledgers.

## Scope
- Extend record summaries with optional claim context where relevant.
- Surface pending-canonical, superseded, par

[Read the thread](https://github.com/maxwellsantoro/dotrepo/issues/49) · 2026-03-10 · closed · 2 comments

### Add read-only CLI and MCP claim inspection surfaces

## Summary
Add read-only CLI and MCP claim-inspection commands over the shared core claim reports.

Part of #34.

## Why
Once core can load and serialize claim-inspection reports, maintainers, reviewers, and agents need first-class read-only surfaces to inspect that data without reading raw claim files.

## Scope
- Add a CLI command or subcommand for claim inspection.
- Add matching MCP tools or tool extensions for claim inspection.
- Reuse the same shared core reports in both surfaces.
- Docume

[Read the thread](https://github.com/maxwellsantoro/dotrepo/issues/48) · 2026-03-10 · closed · 2 comments

### Add shared core claim-inspection reports

## Summary
Add shared core claim-inspection report types and loaders for read-only maintainer-claim inspection.

Part of #34.

## Why
Phase 2 in RFC 0013 begins with read-only inspection. CLI, MCP, and later public surfaces need one shared core report model for claim state, targets, handoff outcomes, and event history.

## Scope
- Add read-only core reports for claim inspection.
- Expose current claim state, targets, handoff outcomes, and ordered events.
- Keep the report model aligned with RFC 

[Read the thread](https://github.com/maxwellsantoro/dotrepo/issues/47) · 2026-03-10 · closed · 2 comments

### Harden stdio transport for dotrepo-lsp and dotrepo-mcp

## Summary
Harden the shared stdio transport story for `dotrepo-lsp` and `dotrepo-mcp` so request framing and payload handling do not rely on duplicated hand-rolled loops.

## Why
Both servers currently parse `Content-Length` framing manually. That is acceptable for the first pass, but it is a clear robustness hotspot as client diversity increases.

## Scope
- Decide whether to introduce a shared internal framing layer or adopt a battle-tested transport crate.
- Remove obvious duplication betwee

[Read the thread](https://github.com/maxwellsantoro/dotrepo/issues/36) · 2026-03-10 · closed · 2 comments

### Implement manifest validation and diagnostics over LSP

## Summary
Implement LSP-backed manifest validation and diagnostics for `.repo` authoring.

## Why
Validation is already a strong part of the CLI and MCP story. The first editor integration should reuse that strength rather than inventing separate editor semantics.

## Scope
- Expose validation diagnostics over LSP for `.repo` files.
- Reuse core validation logic and messages where practical.
- Map diagnostics into editor-friendly ranges and severities.
- Cover common authoring mistakes in nativ

[Read the thread](https://github.com/maxwellsantoro/dotrepo/issues/28) · 2026-03-09 · closed · 2 comments

### Add RFC examples and fixtures for authority handoff scenarios

## Summary
Add concrete examples and tests for authority handoff and conflict scenarios.

## Why
The protocol risk here is social and semantic. We need examples that make the intended behavior obvious to contributors and future implementers.

## Scope
- Add worked examples for:
  - overlay only
  - canonical only
  - canonical superseding overlay
  - multiple conflicting overlays
  - reviewed/verified overlay that is still non-canonical
- Add test fixtures or example records where practical.
- C

[Read the thread](https://github.com/maxwellsantoro/dotrepo/issues/18) · 2026-03-09 · closed · 2 comments

## Most recent

### Add core report types for claim, supersede, and conflict metadata

## Summary
Add shared `dotrepo-core` report objects for authority handoff and conflict reporting.

## Why
CLI and MCP are intentionally aligned through shared core reports. Conflict handling should follow the same pattern instead of introducing separate semantics per surface.

## Scope
- Add serializable core structs for:
  - record identity
  - precedence decision
  - supersede relationship
  - conflicting field claims
- Make the structs reusable by CLI and MCP.
- Ensure the data model preserve

[Read the thread](https://github.com/maxwellsantoro/dotrepo/issues/15) · 2026-03-09 · closed · 2 comments

### Specify conflict surfacing contract for query and trust outputs

## Summary
Define how query and trust surfaces report preferred values, competing claims, and superseded records.

## Why
dotrepo's query contract is trust-aware by design. Today it returns a value plus record trust context, but the next phase needs a first-class way to surface conflicts when multiple records describe the same repo.

## Scope
- Define response shape additions for conflict-aware query results.
- Define response shape additions for trust inspection.
- Decide whether conflict surfa

[Read the thread](https://github.com/maxwellsantoro/dotrepo/issues/14) · 2026-03-09 · closed · 2 comments

### Define claim and supersede semantics for canonical vs overlay records

## Summary
Define the protocol-level rules for how canonical in-repo records relate to overlays that describe the same repository.

## Why
The project's current next constraint is maintainer authority handoff and conflict visibility. We need explicit semantics for when a canonical `.repo` claims authority over an existing overlay, what "supersede" means, and what remains visible after that handoff.

## Scope
- Define repository identity matching for handoff purposes.
- Define what it means for a

[Read the thread](https://github.com/maxwellsantoro/dotrepo/issues/13) · 2026-03-09 · closed · 2 comments

### Add CLI and MCP semantic parity tests

## Owner Role
MCP/Integration

## Depends On
#8

## Description
Encode the canonical maintainer-flow scenarios as parity tests to ensure CLI and MCP return the same semantics and trust context.

## Acceptance Criteria
- `validate`, `query`, `trust`, `generate --check`, and import preview scenarios are semantically identical across CLI and MCP.
- Parity is enforced in CI.
- There is zero intentional semantic drift between surfaces.

[Read the thread](https://github.com/maxwellsantoro/dotrepo/issues/9) · 2026-03-09 · closed · 1 comment

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