Skip to content

docs: correct stale README claims, and signpost store migration from the tutorial path - #259

Open
blarghmatey wants to merge 2 commits into
witan-core-docs-pagefrom
witan-readme-accuracy
Open

docs: correct stale README claims, and signpost store migration from the tutorial path#259
blarghmatey wants to merge 2 commits into
witan-core-docs-pagefrom
witan-readme-accuracy

Conversation

@blarghmatey

Copy link
Copy Markdown
Member

An audit of all 38 READMEs, prompted by two witan-core claims the #255 review
caught. The mechanical half — checking that every referenced path resolves —
found one real breakage; the rest came from reading claims against the code.

packages/witan-core/README.md was describing an earlier package.

  • It listed 2 of 5 extras. Added remote, observability, and sentry,
    with the note that sentry is additive to observability rather than an
    alternative: telemetry.py imports observability.logging, which imports
    structlog at module scope, so sentry alone is an ImportError.
  • Its "what's here" list covered 9 of 22 modules. Documented the missing
    ones: cli, identity, remote/, observability/, omnigraph_http,
    chunking, caching.
  • It ended with "still local to each server: the CLI scaffolding", which is now
    the opposite of the truth — witan_core.cli provides make_app,
    resolve_author, and report_install to both servers.

witan-code is no longer local-only, in three places. The README described
the code graph as a "per-repo, local-only" store and its table said
"no — local only" under Synced. A code graph can now live on a shared
omnigraph-serverWITAN_CODE_SERVER in-cluster, or through the deployed
witan MCP tier from outside it — where a CI indexer owns each repo's default
view and other writers get per-actor branch views. The bridge store has a
cluster graph id (code-bridge) for the same reason. mcp/servers/witan's
README repeated the claim in passing; corrected there too, keeping the
distinction it was actually drawing, which is that those stores are
re-derivable, not that they are local.

packages/agent-kit/README.md quoted floors that had moved
witan-council>=0.2.0, witan-code>=0.2.0 against a real >=0.7.2 and
>=0.8.0. Rather than restate values that will drift again, it now says what
the floors are for and points at pyproject.toml, since duplicating a number
that lives elsewhere is what caused this.

The root README predated witan. Its structure block listed neither
packages/witan-core/, docs/, docker/, nor bin/, and filed the two
servers under a generic "install helpers for common MCP servers" line — the
three published packages that are now the repo's main artifacts were invisible.

One genuinely broken path: mcp/servers/witan/policy/README.md cited
tests/../test_render_groups.py, which resolves to the parent directory rather
than ../tests/.

Also corrected a claim I introduced myself yesterday: AGENTS.md linked
https://witan-context.readthedocs.io as though it were live. That project is
not registered yet, so both it and the new root-README pointer now say the site
is set up to publish there rather than asserting a URL that 404s today.

Left alone deliberately: cross-repo references (ol-infrastructure paths,
upstream omnigraph docs), package-root-relative module shorthand, and
packages/witan-core/CHANGELOG.md's docs/design/… path, which records where
the file was at the time.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_017oVnpzjRJQVWq9hJGE2Rs7


Stack created with GitHub Stacks CLIGive Feedback 💬

An audit of all 38 READMEs, prompted by two `witan-core` claims the #255 review
caught. The mechanical half — checking that every referenced path resolves —
found one real breakage; the rest came from reading claims against the code.

**`packages/witan-core/README.md` was describing an earlier package.**

- It listed **2 of 5 extras**. Added `remote`, `observability`, and `sentry`,
  with the note that `sentry` is additive to `observability` rather than an
  alternative: `telemetry.py` imports `observability.logging`, which imports
  `structlog` at module scope, so `sentry` alone is an ImportError.
- Its "what's here" list covered **9 of 22 modules**. Documented the missing
  ones: `cli`, `identity`, `remote/`, `observability/`, `omnigraph_http`,
  `chunking`, `caching`.
- It ended with "still local to each server: the CLI scaffolding", which is now
  the opposite of the truth — `witan_core.cli` provides `make_app`,
  `resolve_author`, and `report_install` to both servers.

**`witan-code` is no longer local-only, in three places.** The README described
the code graph as a "per-repo, local-only" store and its table said
"**no — local only**" under Synced. A code graph can now live on a shared
`omnigraph-server` — `WITAN_CODE_SERVER` in-cluster, or through the deployed
witan MCP tier from outside it — where a CI indexer owns each repo's default
view and other writers get per-actor branch views. The bridge store has a
cluster graph id (`code-bridge`) for the same reason. `mcp/servers/witan`'s
README repeated the claim in passing; corrected there too, keeping the
distinction it was actually drawing, which is that those stores are
*re-derivable*, not that they are local.

**`packages/agent-kit/README.md` quoted floors that had moved** —
`witan-council>=0.2.0`, `witan-code>=0.2.0` against a real `>=0.7.2` and
`>=0.8.0`. Rather than restate values that will drift again, it now says what
the floors are *for* and points at `pyproject.toml`, since duplicating a number
that lives elsewhere is what caused this.

**The root README predated witan.** Its structure block listed neither
`packages/witan-core/`, `docs/`, `docker/`, nor `bin/`, and filed the two
servers under a generic "install helpers for common MCP servers" line — the
three published packages that are now the repo's main artifacts were invisible.

**One genuinely broken path**: `mcp/servers/witan/policy/README.md` cited
`tests/../test_render_groups.py`, which resolves to the parent directory rather
than `../tests/`.

Also corrected a claim I introduced myself yesterday: `AGENTS.md` linked
`https://witan-context.readthedocs.io` as though it were live. That project is
not registered yet, so both it and the new root-README pointer now say the site
is set up to publish there rather than asserting a URL that 404s today.

Left alone deliberately: cross-repo references (`ol-infrastructure` paths,
upstream omnigraph docs), package-root-relative module shorthand, and
`packages/witan-core/CHANGELOG.md`'s `docs/design/…` path, which records where
the file was at the time.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017oVnpzjRJQVWq9hJGE2Rs7
The site documented local→shared migration thoroughly and then hid it. The
migration runbook was reachable only from the guides index and an ADR, while
the natural journey — install locally, use it for a while, then move onto the
team's shared store — starts in Get started, which pointed at
`deployed-witan.md` and nothing else.

Those two guides answer different questions, and conflating them is the reason
the gap was easy to miss: `deployed-witan.md` points your *client* at a
deployment, `migration-runbook.md` brings your *data* there. Someone who
followed the tutorial and accumulated a graph needs the second, and had to
already know it existed to find it.

- Get started now names both jobs, before the reader has a graph worth keeping,
  and links the runbook's "Local → shared: the cutover" section directly.
- The guides index's "Things people commonly need" table gains a row for each,
  phrased as the question someone actually arrives with rather than the
  document's title.

The migration row also carries the one fact that makes this a procedure rather
than a file copy — a store cannot be moved by copying the directory — because
that is the thing a reader most needs to learn *before* they try it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017oVnpzjRJQVWq9hJGE2Rs7
Copilot AI balanced review requested due to automatic review settings August 19, 2026 19:34
@blarghmatey
blarghmatey force-pushed the witan-readme-accuracy branch from feaa4fe to 2916358 Compare August 19, 2026 19:34
@blarghmatey blarghmatey changed the title docs: correct stale and inaccurate claims across the repo READMEs docs: correct stale README claims, and signpost store migration from the tutorial path Aug 19, 2026

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Updates repository documentation to reflect current witan packaging, shared storage, migration, and publishing behavior.

Changes:

  • Expands package and repository-structure documentation.
  • Corrects stale storage, dependency, and path claims.
  • Signposts local-to-shared migration guidance.

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 3 comments.

Show a summary per file
File Description
README.md Expands repository and package overview.
packages/witan-core/README.md Documents extras and shared modules.
packages/agent-kit/README.md Removes duplicated dependency floors.
mcp/servers/witan/README.md Revises code-store durability wording.
mcp/servers/witan/policy/README.md Corrects a test path.
mcp/servers/witan-code/README.md Documents shared code graphs.
docs/guides/index.md Adds deployment and migration links.
docs/getting-started/index.md Explains migration and client setup.
AGENTS.md Corrects Read the Docs status.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment thread README.md
Comment on lines +3 to +4
A shared toolkit of AI agent utilities for the team. It holds three published
Python packages — [`witan-council`](./mcp/servers/witan/README.md),
reads, an HTTP endpoint one service serves and another calls, a package one repo
publishes and others import. The bridge records these as **interface bindings**
in a single shared, local-only store (`_bridge.omni`, a sibling of the per-repo
in a single shared store (`_bridge.omni` locally, a sibling of the per-repo
Comment on lines +174 to +176
(re-derivable caches `branches --prune` may destroy at any time — shareable
now, but still rebuildable from the source tree, which is the distinction that
matters here).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants