Skip to content

docs(dev): ledger update — cross-repo drift status #294

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
aaltshuler merged 1 commit into from
Jun 20, 2026
+13 −11
Merged

docs(dev): ledger update — cross-repo drift status #294

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 13 additions & 11 deletions docs/dev/docs-issues.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -40,17 +40,19 @@ fixed. Branch `docs/user-coherence-0-7-1`.
`apply_schema_update_and_dependent_query_in_one_run`,
`apply_blocks_graph_delete_without_approval`). Update these comments in a
cluster-crate change.
- **Cross-repo drift from this sweep** (separate repos — track here, fix in a
follow-up in each repo):
- `omnigraph-ts` SDK ships a stale generated `spec/openapi.json` +
`packages/sdk/src/generated/types.gen.ts` still describing the `GET /queries`
catalog as the `mcp.expose` subset. Regenerate from this repo's
`openapi.json` once the SDK's deferred refresh happens (the SDK is known to
lag the API by design).
- `omnigraph-cookbooks/docs/best-practices.md` (~line 372) still describes
client-side auth as resolving through the removed `bearer_token_env` chain.
Update to the keyed-credential model (`OMNIGRAPH_TOKEN_<NAME>` →
credentials file → `OMNIGRAPH_BEARER_TOKEN`).
- **Cross-repo drift from this sweep** (separate repos):
- `omnigraph-ts` SDK — its generated `spec/openapi.json` +
`packages/sdk/src/generated/types.gen.ts` still describe the `GET /queries`
catalog as the `mcp.expose` subset. **No hand-fix:** the SDK's
`scripts/sync-spec.ts` pulls openapi.json from a *tagged* omnigraph release
(`/omnigraph/v{version}/openapi.json`), and the catalog fix landed on main
*after* the v0.7.1 tag — so it is in no tag yet and a hand-edit would be
overwritten on the next sync. It flows in automatically when the SDK bumps
to a tag containing the fix (v0.7.2+). Tracked, not actioned.
Comment on lines +45 to +51

@greptile-apps greptile-apps Bot Jun 20, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

P2 The omnigraph-ts SDK's package.json currently pins omnigraph.serverVersion to "0.7.0", not "0.7.1". The ledger's "v0.7.2+" ceiling is still correct (the fix post-dates the v0.7.1 tag), but noting 0.7.0 as the current pin would make the lag explicit — a reader looking at the SDK today would see it is two minor versions behind, not one. See omnigraph-ts/package.json.

Suggested change
`packages/sdk/src/generated/types.gen.ts` still describe the `GET /queries`
catalog as the `mcp.expose` subset. **No hand-fix:** the SDK's
`scripts/sync-spec.ts` pulls openapi.json from a *tagged* omnigraph release
(`/omnigraph/v{version}/openapi.json`), and the catalog fix landed on main
*after* the v0.7.1 tag — so it is in no tag yet and a hand-edit would be
overwritten on the next sync. It flows in automatically when the SDK bumps
to a tag containing the fix (v0.7.2+). Tracked, not actioned.
`packages/sdk/src/generated/types.gen.ts` still describe the `GET /queries`
catalog as the `mcp.expose` subset. **No hand-fix:** the SDK's
`scripts/sync-spec.ts` pulls openapi.json from a *tagged* omnigraph release
(`/omnigraph/v{version}/openapi.json`), and the catalog fix landed on main
*after* the v0.7.1 tag — so it is in no tag yet and a hand-edit would be
overwritten on the next sync. It flows in automatically when the SDK bumps
to a tag containing the fix (v0.7.2+). SDK currently pins `serverVersion`
`"0.7.0"` (two versions behind). Tracked, not actioned.

Fix in Claude Code

- `omnigraph-cookbooks/docs/best-practices.md` `bearer_token_env` chain —
**RESOLVED** by omnigraph-cookbooks PR #26 (2026-06-21), which deleted
`docs/best-practices.md` as part of the 0.7 restructure; the stale chain
survives nowhere on `main`.
Comment on lines +43 to +55

@greptile-apps greptile-apps Bot Jun 20, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

P2 RESOLVED item lives in the "Open" section

The section header reads "Open — surfaced 2026-06-20, not yet fixed", but the cookbooks entry is now annotated RESOLVED inline. A future auditor scanning for open work may skim past the inline tag and count it as an outstanding item, especially once the list grows. Consider either removing the resolved bullet entirely (the finding is already captured as a P2 row in the Resolved table above via the bearer_token_env fix), or moving it up into the table with a short "cookbooks docs/best-practices.md deleted (PR #26)" row so the "Open" section stays strictly unresolved items.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

Fix in Claude Code


## Verification checklist (re-run on the next docs audit)

Expand Down