mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-08-07 15:52:52 +03:00
df1ed57876
Notion AI has no public inference API (see closed request #3272), so this adds it as a new entry in the established web-cookie provider category (chatgpt-web, claude-web, grok-web, ...): cookie-based auth via the token_v2 session cookie posted to Notion's undocumented internal POST /api/v3/runInferenceTranscript endpoint, translating its NDJSON transcript-patch stream into OpenAI-compatible chat completions. - NotionWebExecutor (open-sse/executors/notion-web.ts): resolves the token_v2 cookie (+ optional space_id/notion_browser_id), builds a Notion transcript from the chat messages, parses the NDJSON response (cumulative-snapshot semantics, mirroring gemini-web.ts's handling of #7163), and returns a chat.completion or pseudo-streamed SSE response. All error paths route through makeExecutorErrorResult (sanitized). - RegistryEntry under open-sse/config/providers/registry/notion-web/, registered in providers/index.ts REGISTRY and executors/index.ts (alias "nw"). - WEB_COOKIE_PROVIDERS entry (src/shared/constants/providers/web-cookie.ts) with subscriptionRisk + webCookie risk notice, clearly labeled "(Unofficial/Experimental)". - Cookie-probe validator (validateNotionWebProvider) against Notion's getSpaces endpoint, and a webSessionCredentials.ts UI entry for the "Add session cookie" flow. - Regenerated docs/reference/PROVIDER_REFERENCE.md and the provider/translate-path golden snapshot (purely additive diffs); synced the "251 providers" count across README/AGENTS/CLAUDE.md (check:docs-counts STRICT gate). Tests: tests/unit/executor-notion-web.test.ts (22 cases — registry consistency, mocked-upstream request/response translation, NDJSON snapshot parsing, cookie resolution, sanitized error paths) plus the existing executor-web-cookie-sweep, provider-alias-uniqueness, check-provider-consistency, web-session-credentials, and provider-translate-path-golden suites all pass with notion-web included.
changelog.d/ — changelog fragments
A PR never edits CHANGELOG.md directly during the cycle. Instead it adds ONE new
file here — its changelog entry as a fragment. Two PRs never touch the same file, so
changelog merge conflicts (the "CHANGELOG-eat" cascade that forced a re-sync push + full
CI re-run after every sibling merge) are structurally impossible.
Convention
| Directory | Aggregates under |
|---|---|
features/ |
### ✨ New Features |
fixes/ |
### 🐛 Bug Fixes |
maintenance/ |
### 📝 Maintenance |
- Filename:
<PR-number>-<short-slug>.md(e.g.fixes/6700-dockerfile-better-sqlite3.md). The PR number prefix keeps aggregation order deterministic. - Content: the exact bullet line(s) that should land in
CHANGELOG.md, starting with-. Multi-line (continuation) bullets are fine. Keep the repo's credit format:(#PR — thanks @user). - One fragment per PR (rarely more, e.g. a PR that both fixes and adds).
Example
changelog.d/fixes/6496-cloudflare-relay-worker-syntax.md:
- **fix(providers):** Cloudflare relay Worker deploys use Service Worker syntax with `body_part` metadata ([#6496](https://github.com/diegosouzapw/OmniRoute/pull/6496)) — thanks @SeaXen
Aggregation
The release captain (or /generate-release) folds all fragments into CHANGELOG.md and
deletes them:
node scripts/release/aggregate-changelog.mjs # write + delete fragments
node scripts/release/aggregate-changelog.mjs --dry-run # preview only
Fragment well-formedness is enforced by npm run check:changelog-integrity (the same
gate that guards against CHANGELOG-eat for legacy direct edits).