- Add SaaS multi-tenant section to both Chinese and English READMEs
- Add REST API endpoint reference table
- Add SaaS/plan highlights in subtitle and pain-point table
- Bilingual sync
Signed-off-by: Boos4721 <boos4721@icloud.com>
- Add ComfyUI chat assistant description in subtitle
- Add ComfyUI section in core features
- Update both Chinese and English versions
Signed-off-by: Boos4721 <boos4721@icloud.com>
- Replace all Metapi references with BoosAPI
- Remove external service links (GitHub, Docker Hub, Render, Zeabur)
- Simplify structure for self-hosted deployment
- Update both Chinese and English versions
Signed-off-by: Boos4721 <boos4721@icloud.com>
- Rename project from Metapi to BoosAPI across all UI and server strings
- Add ComfyUI conversational agent page (/comfyui-agent)
- Add user management system (register, login, API keys, admin)
- Update Dockerfile and database schema
- Add ComfyUI workflow nodes support
- Update shared contracts and platform configurations
Signed-off-by: Boos4721 <boos4721@icloud.com>
Constraint: main push CI fails on npm audit --omit=dev --audit-level=high after recent merges.
Rejected: Broad npm audit fix output | it updated unrelated dev-only lockfile entries.
Confidence: high
Scope-risk: narrow
Directive: Keep PR audit informational until production dependencies are audited on dev/main consistently.
Tested: ELECTRON_SKIP_BINARY_DOWNLOAD=1 npm ci --prefer-offline --no-audit --no-fund; npm audit --omit=dev --audit-level=high; npm run typecheck:server; npm test -- --run src/server/config.test.ts src/server/settingsRoutePayloads.test.ts
Not-tested: Full GitHub Actions matrix before opening PR.
Merged after updating the PR onto current main and fixing the remaining probe-setting review gaps.\n\nValidation:\n- GitHub checks all passing: Test Core, Typecheck, Build Web/Server/Desktop, Repo Drift Check, Schema SQLite/MySQL/Postgres, CodeQL, CodeRabbit.\n- Local: npm run typecheck\n- Local: npm run repo:drift-check\n- Local: npx vitest run --root . src/server/db/schemaContract.test.ts src/server/db/schemaArtifactGenerator.test.ts src/server/db/schemaIntrospection.test.ts src/server/db/schemaParity.test.ts src/web/api.test.ts src/web/pages/helpers/sitesEditor.test.ts src/web/pages/sites.disabled-models-save.test.tsx src/web/pages/sites.edit-scroll.test.tsx
Refresh the PR onto current main and close the remaining probe-setting review gaps: the primary site save now persists the latency threshold, the site row type carries that field without an any-cast, active probe streams are aborted on unmount, and all-model one-shot probes get the longer timeout they need.
Constraint: PR #510 must preserve the per-site model probe feature while merging cleanly into current main.
Rejected: Leave threshold persistence behind the separate probe-settings button | the primary save path would still silently drop user changes.
Rejected: Keep the SiteRow any-cast | it hides API/schema drift for the new persisted field.
Confidence: high
Scope-risk: narrow
Directive: Keep probe setting fields represented in the typed site save payload and covered by focused web API/editor tests.
Tested: npm run typecheck; npm run repo:drift-check; npx vitest run --root . src/server/db/schemaContract.test.ts src/server/db/schemaArtifactGenerator.test.ts src/server/db/schemaIntrospection.test.ts src/server/db/schemaParity.test.ts src/web/api.test.ts src/web/pages/helpers/sitesEditor.test.ts src/web/pages/sites.disabled-models-save.test.tsx src/web/pages/sites.edit-scroll.test.tsx
Not-tested: Full npm test.
The release branch had fallen behind current main and only conflicted in the
Update Center recent-tag test. Keep the latest main-side deploy-state coverage
while preserving the PR's raw-tag filtering and digest visibility assertions.
Constraint: PR #495 must merge into the current main without widening the PR diff beyond the update-center candidate behavior.
Rejected: Drop the PR-specific digest/raw-tag assertions | would regress the review fixes that prompted the branch update.
Confidence: high
Scope-risk: narrow
Directive: Keep recent Docker tag cards deployable only from real tagName values and keep digest metadata visible before deployment.
Tested: npx vitest run --root . src/web/pages/settings/UpdateCenterSection.test.tsx src/server/services/updateCenterVersionService.test.ts src/server/routes/api/updateCenter.test.ts src/server/services/updateCenterStatusService.test.ts; npm run typecheck; npm run repo:drift-check; git diff --cached --check origin/main
Not-tested: Full npm test.
This merge keeps PR #533 aligned with dev after addressing CodeRabbit follow-up test comments. The changes are limited to UpdateCenterSection test assertions.
Constraint: Release branch remains the publication branch for the open main-targeting PR.
Confidence: high
Scope-risk: narrow
Tested: npx vitest run --root . src/web/pages/settings/UpdateCenterSection.test.tsx
Tested: npm run typecheck:web
Co-authored-by: OmX <omx@oh-my-codex.dev>
CodeRabbit follow-up review pointed out that one renderer assertion could not fail usefully and that the new recent-candidate deploy test did not prove log streaming after dispatch. The test now asserts the visible candidate text directly and covers streamUpdateCenterTaskLogs for the new deploy path.
Constraint: Keep review follow-up scoped to test coverage only.
Confidence: high
Scope-risk: narrow
Tested: npx vitest run --root . src/web/pages/settings/UpdateCenterSection.test.tsx
Tested: npm run typecheck:web
Co-authored-by: OmX <omx@oh-my-codex.dev>
The release branch is main-based and tracks the reviewed dev slice for PR publication. This merge carries the post-review compatibility fixes without rewriting the already-open PR history.
Constraint: PR #533 publishes dev changes through a clean release branch targeting main.
Rejected: Recreate the PR branch from scratch | unnecessary churn after green checks and review context already exist.
Confidence: high
Scope-risk: narrow
Tested: npx vitest run --root . src/server/proxy-core/responsesPreflight.test.ts src/server/proxy-core/serviceTierPolicy.test.ts src/server/routes/proxy/chat.stream.test.ts src/web/pages/settings/UpdateCenterSection.test.tsx
Tested: npm run typecheck:server
Tested: npm run typecheck:web
Tested: npm run repo:drift-check
Co-authored-by: OmX <omx@oh-my-codex.dev>
Review feedback found narrow compatibility regressions in the web-search shim, Responses tool detection, service tier accounting, and update-center Docker candidate actions. The fix keeps synthetic search routed through the dedicated search model, preserves Responses text compatibility, distinguishes absent service_tier from filtered service_tier, and evaluates recent Docker tags per candidate.
Constraint: Review fixes must stay on dev first, then flow into the main-based release PR branch.
Rejected: Leave Responses web_search simulation on the request model | it has the same search-route selection risk as Anthropic simulation.
Confidence: high
Scope-risk: narrow
Tested: npx vitest run --root . src/server/proxy-core/responsesPreflight.test.ts src/server/proxy-core/serviceTierPolicy.test.ts src/server/routes/proxy/chat.stream.test.ts src/web/pages/settings/UpdateCenterSection.test.tsx
Tested: npm run typecheck:server
Tested: npm run typecheck:web
Tested: npm run repo:drift-check
Co-authored-by: OmX <omx@oh-my-codex.dev>
Several downstream clients send non-cache compatibility fields across Chat, Responses, Anthropic Messages, and Responses WebSocket surfaces. The proxy now normalizes legacy functions/function_call, maps web_search tools across protocols, rejects unsupported HTTP Responses continuation shapes before upstream dispatch, and applies configurable service_tier policy consistently before requests leave the server.
Constraint: Publication flow keeps day-to-day commits on dev and opens main PRs from a release branch.
Constraint: No new dependencies; web_search-only simulation reuses the existing local search route.
Rejected: Forward external HTTP previous_response_id to strict upstreams | it produces ambiguous continuation failures and stale retry behavior outside WebSocket state.
Rejected: Add a dedicated search dependency | existing /v1/search route is sufficient for synthetic server-tool responses.
Confidence: high
Scope-risk: moderate
Directive: Keep Responses HTTP continuation checks aligned with WebSocket continuation support before relaxing these guards.
Tested: npm run typecheck:server
Tested: npx vitest run --root . src/server/proxy-core/responsesPreflight.test.ts src/server/proxy-core/serviceTierPolicy.test.ts src/server/test-fixtures/protocol/non-cache-field-matrix.test.ts src/server/transformers/openai/responses/conversion.test.ts src/server/transformers/anthropic/messages/conversion.test.ts src/server/routes/proxy/chat.stream.test.ts src/server/routes/proxy/responses.codex-oauth.test.ts
Tested: npx vitest run --root . src/server/routes/proxy/responses.websocket.test.ts
Tested: npm run repo:drift-check
Not-tested: Full application build and full Vitest suite
Co-authored-by: OmX <omx@oh-my-codex.dev>
MySQL information_schema.COLUMNS.COLUMN_DEFAULT stores DEFAULT '' as an
empty string, not NULL. normalizeDefaultValueForColumn was treating any
empty rawDefaultValue as 'no default' and returning null, causing the
MySQL schema parity test to see defaultValue: null for post_refresh_probe_model
while schemaContract.json (generated from TypeScript schema) had "''".
Fix: when rawDefaultValue is empty string, return "''" for text/json columns
instead of null, so the round-trip through MySQL introspection matches the
contract.
Better-SQLite3 requires --> statement-breakpoint between each statement
in a migration file; without it all statements are passed as a single
string to Database.prepare() which throws RangeError on multi-statement input.
- Fix SSE abort: propagate AbortSignal to worker pool; close connection
immediately on client disconnect without sending 'complete' event
- Fix Boolean coercion: use strict === true/=== 1 check instead of Boolean()
to avoid Boolean('false') === true foot-gun
- Fix probe-now: parse and forward latencyThresholdMs from request body
- Fix api.ts probeSiteNow: add latencyThresholdMs to options type
- Fix backup import: restore postRefreshProbe* fields when inserting sites
so that backup/restore round-trips preserve per-site probe config
- Fix latency threshold persistence: add postRefreshProbeLatencyThresholdMs
column (migration 0026), save/load it in site editor, pass to
runPostRefreshProbeIfEnabled so auto-probe also respects the threshold
- Fix state management: setProbeCompleted(false) at probe start; error
branch also refreshes model lists and sets probeCompleted to show results
- Regenerate schema artifacts (mysql/postgres bootstrap+upgrade, contract)
- Move post-refresh probe settings from global config to per-site (sites table)
- Add manual 'probe now' button in site editor with real-time SSE log stream
- Use fetch+ReadableStream instead of EventSource to support Authorization header
- Concurrent probe execution (default 10 workers) via worker-pool pattern
- Add stop button to cancel in-flight probe while preserving completed results
- Add latency threshold: auto-disable models exceeding response time limit
- Treat inconclusive probe results as unsupported (auto-disable)
- Show specific failure reason in logs (timeout, no token, model not found, etc.)
- Refresh and display post-probe model status list (green=available, red=disabled)
- Remove probe settings from global Settings page and RuntimeSettingsPayload
Review feedback pointed out two small but important operator-facing gaps in the
recent-tag card: one-click deploy should only be available when a real raw
Docker tag exists, and the digest that will be deployed should be visible on
the card instead of remaining implicit. This patch tightens the candidate
filter to require tagName and renders the digest metadata before the deploy
actions, with regression coverage for both behaviors.
Constraint: The deploy API still requires a raw Docker tag, not a normalized display value
Constraint: The recent-tag card should surface the exact digest operators are about to deploy
Rejected: Keep accepting normalizedVersion-only candidates | could enable one-click deploy with a non-tag display value
Rejected: Rely on displayVersion alone for digest visibility | digest presence should stay explicit even if display text changes later
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Any future recent-tag UI should treat tagName as the deployable identity and digest as separately visible metadata
Tested: src/web/pages/settings/UpdateCenterSection.test.tsx, npm run typecheck, git diff --check
Not-tested: Full PR checks rerun pending after push
This release branch snapshots the latest dev work onto current main so the
update center can surface recent non-stable Docker tags without operators
looking them up manually. The branch keeps stable Docker discovery as the
primary path while carrying the new recent-tag auto-discovery, UI affordances,
and regression coverage through the repo's release flow.
Constraint: Publication must start from latest origin/main and merge origin/dev on a clean release branch
Constraint: Stable Docker Hub discovery semantics must remain intact while adding recent non-stable discovery
Rejected: Re-open or reuse the already-merged PR #494 branch | it has already been absorbed by main and deleted remotely
Rejected: Publish directly from dev | repo workflow requires a clean release branch to main
Confidence: high
Scope-risk: moderate
Reversibility: clean
Directive: Keep future dev-tag publication work on fresh release branches cut from origin/main; do not revive merged release branches
Tested: Focused update-center vitest suite, npm run typecheck, npm run repo:drift-check, npm run build:web, npm run docs:build, git diff --check (release branch)
Not-tested: Full npm test remains red because tmp/sub2api frontend suites are still broken in this repo snapshot
The update center already allowed manual Docker tag deploys, but operators
still had to know and paste dev or branch tags by hand. This change keeps the
stable Docker Hub candidate as the main path while automatically surfacing the
most recent non-stable tags and their digests for one-click deployment.
Constraint: Stable Docker Hub discovery must remain the default candidate path
Constraint: Existing deploy API and helper protocol should stay unchanged
Rejected: Promote dev tags into the primary stable candidate slot | would blur stable and experimental release semantics
Rejected: Add a brand new backend deploy endpoint for recent tags | existing targetTag/targetDigest deploy path already covers the need
Confidence: high
Scope-risk: moderate
Reversibility: clean
Directive: Keep stable and recent non-stable Docker tag discovery distinct unless product semantics deliberately change
Tested: Focused vitest for update-center services/routes/UI, npm run typecheck, npm run repo:drift-check, npm run build:web, npm run docs:build, git diff --check
Not-tested: Full npm test remains red because tmp/sub2api frontend suites are still broken in this repo snapshot
The last CI failure after the review cleanup was only a stale test expectation:
function_call fallback items now correctly use fc_* item ids while preserving the
call_* id in call_id. Updating the test keeps the suite aligned with the
Responses payload shape we intentionally adopted in the bridge.
Constraint: Keep the fix to the assertion only; the production behavior already matches the reviewed contract
Rejected: Revert the fc_* item id change | that would reopen the review thread we intentionally fixed
Confidence: high
Scope-risk: narrow
Directive: When bridge output semantics change intentionally, update sibling facade tests in the same PR so CI reflects the new contract immediately
Tested: Focused vitest for openai responses outbound/response bridge, Gemini request bridge, Settings payload rules; typecheck; git diff --check
Not-tested: Full npm test
One last review thread caught a real UI regression: the visual payload-rule
editor had drifted away from the shared protocol option source and no longer
exposed several active platform targets. Rebinding the dropdown to the shared
option list fixes the regression without inventing another source of truth.
Constraint: The fix should reuse the existing shared option list instead of creating another hardcoded protocol subset
Rejected: Expand the inline array manually | would repeat the same drift problem that caused the regression
Confidence: high
Scope-risk: narrow
Directive: Payload-rule protocol selectors should always read from the shared option source so Settings and the payload-rule parser stay aligned
Tested: settings.payload-rules vitest; typecheck; git diff --check
Not-tested: Full npm test
The remaining review threads were down to route alias hygiene, proxy-safe header
ordering, and a Gemini canonical tool-result mismatch. This commit makes the
alias/websocket behavior explicit, preserves contributor helper safety, and
teaches the canonical Gemini path to recover tool names and wrap function
results the same way the OpenAI-shaped path already does.
Constraint: Keep the last review fixes limited to the current branch so the release PR stays easy to reason about
Rejected: Defer the Gemini canonical fix to a later refactor | the review found a real functional mismatch and the fix stayed localized to the request bridge
Confidence: high
Scope-risk: narrow
Directive: Keep canonical-to-provider bridges internally consistent; if one path resolves tool names or wraps results, the sibling path should not diverge silently
Tested: Focused vitest for Gemini request bridge, route aliases, upstream request builder, responses response bridge, contributor updater; typecheck; git diff --check
Not-tested: Full npm test; any broader end-to-end Gemini live-provider behavior outside the covered bridge tests
The latest review pass found a few more concrete edge-cases that were still
cheap to close: invalid /responses aliases could still rewrite typos, websocket
session headers should prefer proxy-safe dashed forms, contributor rendering
needed an input guard, and several upstream request/response helpers still had
small contract mismatches around Accept/beta handling and synthesized tool ids.
These fixes keep the release branch behavior explicit while the PR remains open.
Constraint: Keep changes surgical and well-covered so the review cleanup does not destabilize the already-green release branch
Rejected: Leave these for post-merge cleanup | they were still active review threads with straightforward fixes
Confidence: high
Scope-risk: narrow
Directive: When alias routes exist only for ergonomics, reject unknown subpaths loudly instead of silently rewriting them
Tested: Focused vitest for contributor updater, route aliases, upstream request builder, openai responses response bridge; typecheck; git diff --check
Not-tested: Full npm test; the remaining Gemini review thread that likely needs a broader canonical-tool-result contract decision
A few review threads still pointed at real behavior mismatches: Anthropic tool
JSON deltas were still trimming whitespace, Responses conversion still raised
low token caps to the floor, and the bare /responses GET alias returned upgrade
messaging that did not match the actual websocket entrypoint. This commit makes
those behaviors explicit and locks them with focused tests.
Constraint: Keep the release branch green while fixing only the review findings that have a clear, testable contract
Rejected: Leave these for a follow-up cleanup PR | they were low-diff and directly blocked comment resolution on the current release PR
Confidence: high
Scope-risk: narrow
Directive: Preserve raw stream delta text unless a downstream protocol explicitly requires normalization; whitespace can be semantic in incremental payloads
Tested: Focused vitest for anthropic stream bridge, responses conversion, route aliases; typecheck; git diff --check
Not-tested: Full npm test; the remaining review threads that still need broader product decisions
The PR still had a few targeted review threads around contributor pagination,
route-layer passthroughs, dead header fallbacks, and synthetic response ids.
These are small enough to settle directly on the release branch without
broadening the merge scope, and they tighten the repo back toward the
service-owned boundaries this refactor is aiming for.
Constraint: Keep the changes narrow and regression-covered so the release PR stays green while review threads are closed out
Rejected: Leave the minor threads for follow-up after merge | they were isolated enough to fix now and would keep noise on the PR
Confidence: high
Scope-risk: narrow
Directive: When a route shim stops serving any route-local behavior, point callers at the owning service instead of keeping a passthrough around
Tested: Focused vitest for contributor updater, openai responses response bridge, upstream request builder, stats proxy logs, architecture boundaries; typecheck; repo drift check; git diff --check
Not-tested: Full npm test; unresolved review threads that still require larger product decisions
The release branch still had unresolved review comments around payload-rule
atomicity, brand blocking, compact fallback controls, and response
compatibility edge-cases. This patch pulls those behaviors back in line with
the intended contracts and adds focused regression coverage for the fragile
bridges.
Constraint: The fixes must stay narrow to the PR branch so review/merge can continue without reopening the larger dev snapshot conflict set
Rejected: Leave outdated-looking threads unresolved until after merge | reviewers still see concrete unfixed regressions in the current release branch
Rejected: Re-run another broad merge from dev/main | too risky while the PR branch is already green and mergeable
Confidence: medium
Scope-risk: moderate
Directive: If these release-branch fixes need to persist for future release cuts, backport them onto dev instead of re-fighting the same review threads next time
Tested: Focused vitest for settings events, brand matcher, compact responses, codex compatibility, anthropic stream bridge, openai chat response bridge; typecheck; repo drift check; git diff --check
Not-tested: Full npm test; live PR thread resolution state after push
The CI workflow already described production dependency audit as an
informational PR signal, but the job still surfaced as a failing check.
That left release PRs in an unstable state even after the real merge-gate
jobs were green. This keeps PR audits visible as warnings while still
letting main-branch pushes fail if production dependency audit actually
returns a non-zero exit.
Constraint: Preserve production audit visibility while avoiding false-red PR status
Rejected: Remove audit from CI entirely | loses vulnerability visibility
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep audit informational on pull requests unless branch protection is intentionally tightened later
Tested: YAML parse via ruby; git diff --check
Not-tested: Full GitHub Actions rerun pending after push
The release branch inherited a few merge-shaped regressions after the
large dev snapshot was layered onto the latest main snapshot. This
commit restores the main-compatible stats and TokenRoutes behavior the
CI suite expects and adds the missing multi-brand helper export so the
release branch reflects a coherent post-merge tree instead of a
partially regressed hybrid.
Constraint: Must keep the release branch mergeable to main while preserving the current publish snapshot shape
Rejected: Re-open the whole release merge and hand-resolve every file again | too broad for targeted CI repair
Confidence: medium
Scope-risk: narrow
Reversibility: clean
Directive: When dev and main have drifted heavily, re-run the main-facing CI tests after any conflict normalization pass
Tested: targeted vitest suite for failing CI jobs plus update-center coverage; typecheck
Not-tested: Full npm test still not representative locally because of unrelated untracked tmp/sub2api suites outside the PR branch content
This release branch starts from the latest origin/main and folds in the
current origin/dev snapshot so the PR to main can follow the repo's
publish flow without opening directly from dev. Conflict-heavy files
were normalized back to the dev snapshot where necessary so the release
branch reflects the code currently being carried on dev instead of a
line-merged hybrid.
Constraint: Publication flow requires a clean release branch from latest origin/main rather than a PR directly from dev
Constraint: The branch must preserve the current dev snapshot even when main and dev have drifted substantially
Rejected: Open the PR directly from dev | violates the repo publication flow
Rejected: Manually redesign every historic dev/main conflict during release prep | too broad for a publish branch
Confidence: medium
Scope-risk: moderate
Reversibility: clean
Directive: Treat this branch as a publication snapshot of dev-on-top-of-main, not as a general cleanup pass over old divergence
Tested: update-center focused vitest suite on release branch; typecheck; build:web; docs:build; repo:drift-check
Not-tested: Full npm test remains red from inherited tmp/sub2api frontend suites and an existing firstByteTimeout unhandled error
The update center previously surfaced stable Docker Hub candidates but
left dev and branch-tag rollouts stranded in SSH and Helm commands.
This adds a repo-native manual Docker tag entrypoint in Settings so
operators can deploy dev, branch, temporary, or sha tags through the
existing helper flow without changing the backend deploy contract.
Constraint: Keep the existing helper API and digest-aware Helm contract unchanged
Constraint: Preserve stable Docker Hub candidate discovery for default reminders
Rejected: Expand automatic Docker Hub discovery to all branch tags | would blur stable release reminders with operator-only rollout targets
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep automatic candidate detection stable-first; manual tag deploy is the escape hatch for non-stable tags
Tested: update-center focused vitest suite; typecheck; build:web; docs:build; repo:drift-check
Not-tested: Full npm test remains red due to unrelated tmp/sub2api frontend suites and an existing firstByteTimeout unhandled error
The transferred dev snapshot was not publication-ready yet: full tests still
failed because worktree-local docs resolution assumed a repo-root node_modules
tree, some protocol expectations no longer matched the refactored request
bridges, oauth/account-token route tests reused stale modules after resetting
DATA_DIR, and model discovery still fired unawaited default-token writes.
This follow-up makes the moved dev branch self-consistent and green again by
stabilizing module/test isolation, awaiting token mirroring writes, and
aligning narrow tests with the current transformer and request-builder
contracts.
Constraint: The fix set had to stay narrow and unblock the new dev branch without reworking the broader transferred refactor
Rejected: Revert the transferred snapshot | would lose the user's requested dev-branch continuation point
Confidence: medium
Scope-risk: moderate
Reversibility: clean
Directive: If more DATA_DIR-scoped API test files start flaking under shared workers, reset modules before importing singleton db/config modules instead of relying on process env mutation alone
Tested: git diff --check; npm run typecheck; npm run repo:drift-check; npm test
Not-tested: Live OAuth/provider flows outside the mocked test harness
The root checkout already contained a large in-progress proxy, transformer,
and settings refactor. This commit captures that exact work on a dedicated
local dev branch without disturbing the original dirty worktree, so the
changes can be continued or split from dev instead of living only as
uncommitted state.
Constraint: The source checkout was already dirty on another branch, so the move had to preserve that worktree while excluding local .idea and .omx residue from the commit
Rejected: Switch the dirty root checkout directly to dev | risked disrupting the original branch and in-progress state
Confidence: medium
Scope-risk: broad
Reversibility: clean
Directive: Treat this as a transfer snapshot; fix the failing oauth/accountTokens/normalized/docs test regressions before merge or publication
Tested: git diff --check; npm run typecheck; npm run repo:drift-check
Not-tested: Clean test pass; npm test currently fails in oauth routes, accountTokens sync, shared normalized helpers, gemini route expectations, architecture-boundaries, and docs vitepress config
* Expose more payload-rule upstream types in Settings
The first payload-rules UI only offered a narrow set of protocol labels, which
made live troubleshooting confusing once real playground traffic routed through
platforms like sub2api instead of codex. This expands the selectable upstream
types, extracts the option list into one small helper, and renames the field to
上游类型 so the UI matches what the runtime matcher actually uses.
Constraint: Must preserve the existing payload-rules schema key (`protocol`) even though the UI wording is now upstream-type oriented
Rejected: Leaving the dropdown codex/openai-only and telling operators to hand-edit JSON | too easy to misconfigure during live routing diagnosis
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: If new canonical site platforms are added, update payloadRuleProtocolOptions.ts so the visual editor stays aligned with runtime matching
Tested: npx vitest run --root . src/web/pages/settings.payload-rules.test.tsx src/web/pages/settings.payload-rule-platform-options.test.ts
Tested: npm run typecheck:web
Tested: npm run typecheck:web:test
Tested: npm run repo:drift-check
Not-tested: Manual dropdown interaction in a browser
* Keep payload-rule upstream types aligned with one-api backend support
Code review caught that the visual editor still omitted one-api even though the
backend continues to treat it as a valid upstream platform. This adds the
missing option and extends the focused option-set test so operators can create
payload rules for one-api without dropping to raw JSON.
Constraint: Must preserve the runtime payload-rules schema and only close the UI/backend option gap
Rejected: Removing one-api from the backend in this PR | unrelated behavioral change and broader migration risk
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: When backend platform support changes, update payloadRuleProtocolOptions.ts and its focused test in the same PR
Tested: npx vitest run --root . src/web/pages/settings.payload-rules.test.tsx src/web/pages/settings.payload-rule-platform-options.test.ts
Tested: npm run typecheck:web
Tested: npm run typecheck:web:test
Tested: npm run repo:drift-check
Not-tested: Manual browser check of the expanded dropdown list
* Make payload request overrides configurable from Settings
The payload-rules engine already existed in the proxy path, but operators had
no supported runtime UI to manage CPA-style overrides. This wires the setting
through the runtime settings API, adds strict validation, and ships a
low-friction visual editor with an advanced JSON fallback so common cases like
Codex high reasoning can be configured without hand-editing backend state.
Constraint: Must reuse the existing payload-rules execution path and settings table without schema changes
Constraint: Must fit the existing metapi Settings-page patterns rather than introducing a standalone config surface
Rejected: JSON-only editor as the primary UX | too long and too easy to misconfigure for common cases
Rejected: A brand-new backend rule format for the UI | would duplicate the existing payload-rules source of truth
Confidence: high
Scope-risk: moderate
Reversibility: clean
Directive: Keep visual-rule serialization and advanced JSON editing in sync before extending the rule model
Tested: npm run typecheck
Tested: npx vitest run --root . src/server/services/payloadRules.test.ts src/server/routes/api/settings.events.test.ts src/web/pages/settings.payload-rules.test.tsx
Tested: npm run repo:drift-check
Not-tested: Manual browser interaction smoke on the Settings page in this clean PR worktree
* Prevent payload-rules saves from violating review expectations
Code review surfaced two operator-facing edge cases in the first payload-rules
PR: successful rule parsing could still be committed before a later validation
error, and visual edits could silently overwrite unsaved advanced JSON. This
stages payload-rules until the request finishes validating and adds an explicit
confirmation gate before visual actions discard unsynced advanced edits.
Constraint: Keep the fix narrow to the reviewed payload-rules feature without refactoring unrelated runtime-settings atomicity behavior
Rejected: Silently skipping draft resync while keeping visual edits active | would leave save semantics ambiguous when advanced JSON stays dirty
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: If the settings endpoint ever moves toward full request atomicity, re-check this staged payload-rules write path against the broader strategy
Tested: npm run typecheck
Tested: npx vitest run --root . src/server/routes/api/settings.events.test.ts src/web/pages/settings.payload-rules.test.tsx
Tested: npm run repo:drift-check
Not-tested: Manual browser smoke of the confirmation dialog text
The usage aggregation projector was written with SQLite/Postgres conflict builders, but Render can switch the runtime DB to MySQL from saved settings. That made the startup scheduler throw before the service stayed healthy.
This change branches the projector's checkpoint and aggregate writes to MySQL-safe onDuplicateKeyUpdate calls while preserving the existing SQLite/Postgres onConflict behavior. A mocked MySQL regression test now omits the onConflict builders entirely so future regressions fail fast.
Constraint: Drizzle conflict APIs are dialect-specific and the projector starts during boot
Rejected: Disable the projector on MySQL | would keep admin analytics stale and hide the real incompatibility
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: New usage-aggregation writes must branch on runtimeDbDialect before using conflict helpers
Tested: npx vitest run --root . src/server/services/usageAggregationService.test.ts src/server/services/usageAggregationService.mysql.test.ts
Tested: npm run typecheck:server
Tested: npm run repo:drift-check
Tested: npm run build:server
Not-tested: Live MySQL projector pass against a deployed runtime database
* Keep route-detail motion smooth while restoring a more panel-like reveal feel
The route page detail panel originally reused the shared collapse container,
which looked lively but reintroduced layout-heavy motion inside the desktop
route grid. This change keeps the non-layout presence shell, then tunes the
panel animation itself so it reveals from the top with a softer, more
trace-panel-like feel without falling back to grid row interpolation.
Constraint: The desktop route detail panel sits inside a multi-column CSS grid and must avoid layout-driven collapse animation
Rejected: Reuse anim-collapse exactly as ProxyLogs does | reopening grid-template-rows animation brought back jank on route expand/collapse
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Preserve transform/clip-path-based motion here unless grid placement is redesigned; do not reintroduce layout collapse without profiling
Tested: npm test -- src/web/pages/tokenRoutes.desktop-detail-panel.test.tsx src/web/pages/tokenRoutes.group-collapse.test.tsx src/web/pages/token-routes/RouteFilterBar.test.tsx
Tested: npm run typecheck:web
Tested: npm run typecheck:web:test
Tested: npm run repo:drift-check
Not-tested: manual GitHub review in production browser after PR creation
* Keep route-detail motion PR lint-clean without changing behavior
CodeRabbit correctly flagged the new keyframes for using from/to selector
notation. This follow-up keeps the animation timing and properties the same
while switching to percentage selectors so the stylesheet aligns with the
configured keyframe selector rule.
Constraint: Keep the route-detail panel motion unchanged while satisfying the style rule mentioned in PR review
Rejected: Ignore the review comment | leaves a stylelint-style regression in the PR discussion unresolved
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: When adding new keyframes in this stylesheet, prefer explicit percentage selectors to avoid repeating this lint issue
Tested: npm test -- src/web/pages/tokenRoutes.desktop-detail-panel.test.tsx src/web/pages/tokenRoutes.group-collapse.test.tsx src/web/pages/token-routes/RouteFilterBar.test.tsx
Tested: npm run typecheck:web
Tested: npm run repo:drift-check
Not-tested: remote Git transport from this machine still hangs, so branch update was handled separately from local git push
* Respect reduced-motion and narrow layer promotion for route detail panel
The new route detail panel motion path solved grid-driven jank, but the follow-up
review correctly flagged two polish issues: the animation should honor reduced
motion, and will-change should only stay enabled during active transitions. This
keeps the smoother motion path while reducing persistent layer cost and giving
reduced-motion users immediate state changes.
Constraint: Must preserve the non-layout animation path that fixed dropped frames in the route grid
Rejected: Restore anim-collapse behavior | reintroduces grid/layout-driven jank
Confidence: high
Scope-risk: narrow
Directive: Keep desktop route detail motion on transform and clip-path rather than grid height animation unless the panel moves out of the card grid
Tested: npm test -- src/web/pages/tokenRoutes.desktop-detail-panel.test.tsx src/web/pages/tokenRoutes.group-collapse.test.tsx src/web/pages/token-routes/RouteFilterBar.test.tsx
Tested: npm run typecheck:web
Tested: npm run typecheck:web:test
Tested: npm run repo:drift-check
Not-tested: Manual browser validation of prefers-reduced-motion on macOS
* Honor reduced-motion semantics in route detail panel lifecycle
The previous follow-up removed the always-on layer hint and added reduced-motion
CSS, but the enter state still reused the long-lived open class and the desktop
close path kept a fixed JS delay. This narrows will-change to a transient
entering state, bypasses close delays for reduced-motion users, and locks the
behavior with a regression test.
Constraint: Must preserve the non-layout detail-panel motion path that fixed grid jank
Rejected: Keep reduced-motion as CSS-only | JS close timer still delayed unmount and active-state cleanup
Rejected: Drop the close delay globally | would remove the intended close animation for standard-motion users
Confidence: high
Scope-risk: narrow
Directive: If the desktop detail panel motion changes again, keep motion-state CSS and JS timers aligned for prefers-reduced-motion users
Tested: npm test -- src/web/pages/tokenRoutes.desktop-detail-panel.test.tsx src/web/pages/tokenRoutes.group-collapse.test.tsx src/web/pages/token-routes/RouteFilterBar.test.tsx
Tested: npm run typecheck:web
Tested: npm run typecheck:web:test
Tested: npm run repo:drift-check
Not-tested: Manual browser verification of prefers-reduced-motion on macOS
boos
Tursom K. Ulefits