An agent report becomes a document people can review
Slashdocs built in 76 seconds in our sandbox, but its useful promise starts after compilation: an agent publishes an HTML report, a person comments on a specific passage, and the agent publishes a revised version. The old version stays available. That gives a team somewhere to discuss generated work without losing the report and its corrections in a chat history.
The project README makes a self-contained HTML file the document unit. Images can be embedded, and diagrams can use inline SVG or Mermaid. That's convenient for an agent that already emits an architecture review or incident report as an artifact. You still own the substance of that report. Slashdocs provides review and version storage, without establishing that an agent's claims are correct.
What happened when we ran it
Our run installed Slashdocs commit d4f5c29 in 42 seconds, fetching 245 packages, and built it successfully in 76 seconds. We cloned it on October 14, 2026, into a fresh Debian sandbox using golang:1.24-bookworm, with 3 CPUs and 8 GB of RAM. The container had no secrets or elevated privileges. These results establish that the measured source path installed and compiled in that environment.
The test command failed with exit code 1 after 18 seconds. The supplied Go summary reports 24 passed and 5 failed out of 29. Its tail shows failures in cli/internal/cli and internal/render. Named bridge checks concern theme behavior, the postMessage security boundary, message families, document links, the manual-edit contract, and stored document values with undo and redo. Those names describe the checks that failed, without showing their assertion messages.
The supplied summary's 5 failures do not match the larger list of named bridge failures in the tail. We preserve the summary as reported and flag that discrepancy instead of manufacturing a reconciled total. The excerpt also doesn't show why those contracts failed. In particular, a failing security-boundary check is a reason to investigate before deployment, not evidence from this log that uploaded HTML can escape its sandbox.
The checkout contained 472 files, roughly 66,644 lines of source, and occupied 4.5 MB. Our scan found 2 CI workflow files, a Dockerfile, and a Compose file, but no tests directory. The log plainly shows Go checks in package directories. Our measurement method covered source installation, build, and tests. It did not exercise an authenticated deployment or validate the browser's isolation of a hostile document.
The quickstart supplies services that production must replace
The 42-second dependency step doesn't include production identity and storage configuration. The bundled Compose route starts Postgres, an S3-compatible service, and Dex with a development login. The README distinguishes that evaluation stack from a real deployment and offers a published container image. To change the container locally, it documents Compose with Buildx. Those routes are useful, but aren't outcomes from our sandbox run.
Production needs Postgres, an S3-compatible bucket, identity-provider credentials, session secrets, and HTTPS. The self-hosting guide requires different hostnames for the application and rendered documents. Changing only the scheme or port doesn't isolate host-scoped cookies. I'd stop an adoption that cannot provide that separation: the product intentionally accepts untrusted HTML, so the render hostname belongs in the deployment design from the beginning.
MCP avoids a local bridge, while agent access still needs credentials
Slashdocs exposes Streamable HTTP at /mcp, with browser OAuth for interactive clients and service-account bearer keys for unattended agents. The endpoint covers document versions, comments, sharing, and folders. The CLI also installs a bundled skill into agent and Claude Code skill directories. That is a practical fit when a team wants its existing agents to publish artifacts into the same place humans review them.
The README keeps creation of service accounts and bearer keys outside MCP, directing administrators to the web application or CLI. New documents are private by default, with configurable sharing defaults. Choose the agent's access deliberately before connecting it to a workspace. The 24 passing tests in our supplied summary don't prove that an automated publisher has the right permissions for your organization's documents, or that its generated HTML deserves those permissions.
Current reports question comment placement and phone access
Open issue 198 on anchor validation cites v0.2.1 code where a nonexistent or ambiguous quote can be accepted as an attached comment. The report distinguishes this from comments drifting after a later edit. That difference matters: an agent can receive apparent success for feedback the viewer cannot place. PR 209 proposes validation, but it was still open. I'd check placement in the browser before treating the comment response as confirmation.
Open issue 202 on phone-width version history also cites v0.2.1: the history button disappears on narrow screens without a menu alternative. A proposed fix in PR 208 remained open. Teams whose reviewers regularly use phones should wait or verify a fix themselves. These are upstream reports, separate from our 18-second failed test command. They concern the review workflow people would buy into, rather than cosmetic details.
October releases justify evaluation, with identity migration needing care
The repository was pushed on October 14, 2026. GitHub listed 280 stars and 39 open issues and PRs, and release v0.2.1 shipped on October 13. Current work includes a merged notification-name fix and proposed review-interface changes. This is an active project with a small visible audience. The release and push dates support evaluation, while the open reports show where to spend that evaluation effort.
Issue 203 on OIDC issuer changes reports existing-user lockouts after the issuer URL changes and ties the behavior to v0.2.1 identity code. Keep that migration concern in the decision alongside the failed bridge checks. I'd trial Slashdocs for agent-generated HTML reports with desktop reviewers. Choose Outline or Docmost for a wiki-centered team, or HedgeDoc for shared Markdown writing. Adopt Slashdocs after its exact review and recovery paths work for your team.