docs: give witan-core its own page - #255
Open
blarghmatey wants to merge 2 commits into
Open
Conversation
blarghmatey
force-pushed
the
witan-core-docs-page
branch
from
August 19, 2026 15:24
cead5ba to
80d609d
Compare
Contributor
There was a problem hiding this comment.
Pull request overview
Adds a dedicated explanation page for witan-core, covering its architecture, dependencies, shared responsibilities, and version-floor maintenance risk.
Changes:
- Documents
witan-coredesign and contributor guidance. - Links the page from site navigation, indexes, and package listings.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
zensical.toml |
Adds the page to navigation. |
docs/index.md |
Links witan-core to its explanation. |
docs/explanation/witan-core.md |
Adds the explanation page. |
docs/explanation/index.md |
Adds the page to the explanation index. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
blarghmatey
force-pushed
the
witan-core-docs-page
branch
3 times, most recently
from
August 19, 2026 16:09
78e0ecb to
96f90f5
Compare
blarghmatey
added a commit
that referenced
this pull request
Aug 19, 2026
… stale README Review feedback on #255 (Copilot). All three verified against the code; all three were wrong, and two came from trusting `packages/witan-core/README.md` rather than checking what the package does now. **The dependency example was a stale fragment.** The version-floor section showed `"witan-core>=0.13,<1"` as the current declaration. It is `"witan-core[cli,remote,observability,sentry]>=0.25,<1"`. Quoting an obsolete floor in the passage warning contributors about floors undercuts the warning, and could lead someone to pick an already-dead minimum. **`sentry` is additive to `observability`, not an alternative.** The page said the split lets someone take error reporting without the OTel weight. It does not: `telemetry.py` imports `witan_core.observability.logging`, which imports `structlog` at module scope, so `sentry` alone is an ImportError rather than a lighter build — and both servers request both extras anyway. The split runs the other way: a deployment can have structured logs and traces *without* shipping errors to Sentry. **CLI scaffolding is shared, not local.** The page ended by saying it remains local to each server, which is what the README still says. `witan_core.cli` provides `make_app`, `resolve_author`, and `report_install`, and both servers import them — so the sentence told contributors the opposite of the real ownership rule. What stays local is each server's own commands and setup behaviour. The README's own stale sentences are left for a separate change; correcting the package's README is not this PR's business, and the site no longer repeats it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017oVnpzjRJQVWq9hJGE2Rs7
blarghmatey
force-pushed
the
witan-core-docs-page
branch
from
August 19, 2026 16:36
96f90f5 to
fe4541d
Compare
witan-core was the one third of the documented trio with no page. It appeared only as a row in an architecture table and a line in the package list, so a reader wanting to know what it provides had to go read its README in the repo — which is the gap the site exists to close. Written as explanation rather than generated API reference, deliberately. witan-core describes itself as "shared core for the witan MCP servers": it is an internal dependency, not a library third parties build against, and a symbol-by-symbol reference would add a large low-traffic section while implying a stability promise the package does not make. It would also mean adopting mkdocstrings, giving up the site's current no-plugin property — the thing keeping a fall back to mkdocs-material cheap while Zensical is pre-1.0. What the page covers is what a contributor actually needs: - **Why it exists.** Not "shared code" in the abstract, but the specific class of code where two copies drifting is a *correctness* bug: the repo-key canonicaliser, whose output is the join key between the memory and code graphs, and the pinned omnigraph binary version, where a mismatch is a strict-format error rather than an inconsistency. - **The leaf invariant.** witan_core imports neither server, which is what keeps the optional `witan` → `witan-code` mount a DAG instead of a cycle. - **Why the base package is stdlib-only**, and why `observability` and `sentry` are separate extras rather than one. - **The version-floor trap**, which is the thing that will actually bite a contributor. The uv workspace resolves witan-core by path, so adding a witan_core symbol and using it in a server passes locally and in CI, then fails at `pip install` time for anyone resolving from PyPI. Nothing automated catches it — the path resolution is precisely what hides it — and the pin comments record it having happened five times in witan-council and three in witan-code. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017oVnpzjRJQVWq9hJGE2Rs7
… stale README Review feedback on #255 (Copilot). All three verified against the code; all three were wrong, and two came from trusting `packages/witan-core/README.md` rather than checking what the package does now. **The dependency example was a stale fragment.** The version-floor section showed `"witan-core>=0.13,<1"` as the current declaration. It is `"witan-core[cli,remote,observability,sentry]>=0.25,<1"`. Quoting an obsolete floor in the passage warning contributors about floors undercuts the warning, and could lead someone to pick an already-dead minimum. **`sentry` is additive to `observability`, not an alternative.** The page said the split lets someone take error reporting without the OTel weight. It does not: `telemetry.py` imports `witan_core.observability.logging`, which imports `structlog` at module scope, so `sentry` alone is an ImportError rather than a lighter build — and both servers request both extras anyway. The split runs the other way: a deployment can have structured logs and traces *without* shipping errors to Sentry. **CLI scaffolding is shared, not local.** The page ended by saying it remains local to each server, which is what the README still says. `witan_core.cli` provides `make_app`, `resolve_author`, and `report_install`, and both servers import them — so the sentence told contributors the opposite of the real ownership rule. What stays local is each server's own commands and setup behaviour. The README's own stale sentences are left for a separate change; correcting the package's README is not this PR's business, and the site no longer repeats it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017oVnpzjRJQVWq9hJGE2Rs7
blarghmatey
force-pushed
the
witan-core-docs-page
branch
from
August 19, 2026 16:49
fe4541d to
24c49ee
Compare
blarghmatey
added a commit
that referenced
this pull request
Aug 19, 2026
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
blarghmatey
force-pushed
the
witan-core-docs-page
branch
from
August 19, 2026 17:18
24c49ee to
ba47a3e
Compare
blarghmatey
added a commit
that referenced
this pull request
Aug 19, 2026
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
blarghmatey
force-pushed
the
witan-core-docs-page
branch
from
August 19, 2026 19:34
ba47a3e to
24c49ee
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
witan-core was the one third of the documented trio with no page. It appeared
only as a row in an architecture table and a line in the package list, so a
reader wanting to know what it provides had to go read its README in the repo —
which is the gap the site exists to close.
Written as explanation rather than generated API reference, deliberately.
witan-core describes itself as "shared core for the witan MCP servers": it is an
internal dependency, not a library third parties build against, and a
symbol-by-symbol reference would add a large low-traffic section while implying
a stability promise the package does not make. It would also mean adopting
mkdocstrings, giving up the site's current no-plugin property — the thing
keeping a fall back to mkdocs-material cheap while Zensical is pre-1.0.
What the page covers is what a contributor actually needs:
of code where two copies drifting is a correctness bug: the repo-key
canonicaliser, whose output is the join key between the memory and code
graphs, and the pinned omnigraph binary version, where a mismatch is a
strict-format error rather than an inconsistency.
the optional
witan→witan-codemount a DAG instead of a cycle.observabilityandsentryare separate extras rather than one.
contributor. The uv workspace resolves witan-core by path, so adding a
witan_core symbol and using it in a server passes locally and in CI, then
fails at
pip installtime for anyone resolving from PyPI. Nothing automatedcatches it — the path resolution is precisely what hides it — and the pin
comments record it having happened five times in witan-council and three in
witan-code.
Co-Authored-By: Claude Opus 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_017oVnpzjRJQVWq9hJGE2Rs7
Stack created with GitHub Stacks CLI • Give Feedback 💬