Skip to content

docs: give witan-core its own page - #255

Open
blarghmatey wants to merge 2 commits into
witan-context-docs-sitefrom
witan-core-docs-page
Open

docs: give witan-core its own page#255
blarghmatey wants to merge 2 commits into
witan-context-docs-sitefrom
witan-core-docs-page

Conversation

@blarghmatey

Copy link
Copy Markdown
Member

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 witanwitan-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


Stack created with GitHub Stacks CLIGive Feedback 💬

@blarghmatey
blarghmatey force-pushed the witan-core-docs-page branch from cead5ba to 80d609d Compare August 19, 2026 15:24
Copilot AI balanced review requested due to automatic review settings August 19, 2026 15:24

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

Adds a dedicated explanation page for witan-core, covering its architecture, dependencies, shared responsibilities, and version-floor maintenance risk.

Changes:

  • Documents witan-core design 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.

Comment thread docs/explanation/witan-core.md Outdated
Comment thread docs/explanation/witan-core.md Outdated
Comment thread docs/explanation/witan-core.md Outdated
@blarghmatey
blarghmatey force-pushed the witan-core-docs-page branch 3 times, most recently from 78e0ecb to 96f90f5 Compare August 19, 2026 16:09
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
blarghmatey force-pushed the witan-core-docs-page branch from 96f90f5 to fe4541d Compare August 19, 2026 16:36
blarghmatey and others added 2 commits August 19, 2026 12:47
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
blarghmatey force-pushed the witan-core-docs-page branch from fe4541d to 24c49ee Compare August 19, 2026 16:49
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
blarghmatey force-pushed the witan-core-docs-page branch from 24c49ee to ba47a3e Compare August 19, 2026 17:18
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
blarghmatey force-pushed the witan-core-docs-page branch from ba47a3e to 24c49ee Compare August 19, 2026 19:34
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