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.

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 · 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 · 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 · 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 · 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 · 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 · 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 · 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 · 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 · 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 · 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 · 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 · 2026-03-09 · closed · 1 comment

The remaining reports are on the project's issue tracker.