Skip to content

refactor(harness): migrate capabilities through Rutis - #2465

Draft
zerob13 wants to merge 61 commits into
devfrom
dimagent/rutis-harness-bootstrap
Draft

zerob13 wants to merge 61 commits into
devfrom
dimagent/rutis-harness-bootstrap

Conversation

@zerob13

@zerob13 zerob13 commented Oct 25, 2026 •

Copy link
Copy Markdown
Collaborator

DeepChat coordinates Agent execution, Memory and shared persistence in Electron main. This migration moves cohesive owners behind Rutis while retaining the current application contracts, one storage authority and measured resource limits.

Current status:

Runtime and ownership:

  • Invocation admission uses the Rust/Rutis host and a TS plugin by default. Ordering, cancellation, owner limits and bounded transport remain enforced.
  • One lazy native TS vector worker runs under the same host. Kernel file ownership, persistent Agent leases and quarantine fences protect uncertain work and worker loss. Admission survives; recall degrades to FTS, and vector recovery requires explicit rebuilding.
  • Rust stages bounded packed Float32 uploads and dispatches atomic native upserts on commit. Transfer acknowledgements, queue/control reserves, finite/native-buffer validation and strict private-buffer/base64 contracts remain active. Pinned SDK patches retain embedding validation and raw-response isolation.
  • The Scheduler timer helper holds no database connection, path/password or SQL. It requests a bounded Store command selecting at most 100 due jobs and atomically creating deduplicated runs and schedule heads. Dispatch precedes acknowledgement. One correlated scan, coalescing and generation/sequence checks fence missing, stale or duplicate replies.
  • Main supplies the approved Scheduler helper through a cancelable plain command/event/lifecycle facade. The manager has no Electron/filesystem/path imports or optional native-construction fallback. Main also owns the single system-resume listener and suppresses delivery during maintenance/shutdown.

Store and desktop boundaries:

  • MCP Apps keep one registry for instance/source/consent authority. Pending creation consumes the existing 64-total/32-per-owner capacity, and owner/server/maintenance revocation aborts its metadata work without stopping the shared server. Main validates native window identity for observation, protocol responses, browser permission callbacks and approved links. Policy is a plain isolated projection, browser approval checks current source/owner state, and native callbacks settle once. Native session/window/shell imports and their implementation move out of the registry and AppHost into the real protocol adapter; no fallback or second authority is introduced.
  • MCP runtime bootstrap is explicit: Main supplies its absolute home and application version beside the same ToolchainService used elsewhere. Client command rewriting, runtime roots and PATH read the current owner. ServerManager reads the current host proxy URL through a required callback, preserving credentials and later proxy changes. Native/singleton imports and obsolete mocks are removed. No second toolchain owner, process or fallback is introduced; native AppHost presentation remains separate work.
  • Plugin tool policies use one required native-free owner and the existing plugin-tool-policies file adapter. Activation/migration/disable/shutdown and all policy consumers share it. Owner/server replacement, owner-wide removal, allow/ask/deny, undeclared closure, ambiguity and disabled-record behavior remain compatible. Reads reflect the backing store without a second decision cache; write failures propagate. Synchronous reads/mutations stay with their shared authority; G5 must give any retained desktop writer acknowledged commands when that authority moves.
  • Agent tools receive the existing system/profile temporary roots and image-size probe through a required host capability. Main retains nativeImage; only dimensions are returned. The manager validates absolute roots, preserves directory approvals/default-workspace fallback and fences late image results before cache/Provider work. The settings-window handler receives only its original three native window operations. Native image decoding still runs synchronously in Main; no resource gain is claimed.
  • The Store audit maps all runtime SQLite/DuckDB constructor families, inherited shared facades, separate caches and indivisible Session/Tape/Memory/Agent/delegation/Scheduler/Project/Sync transactions. Shared readers and Tape inspector subscriptions require explicit backend data boundaries. Settings ownership applies to the whole physical file: the pinned Conf adapter rewrites complete objects, so different-key Main/backend writers can still lose updates. G5 must hand the existing profile file to one configuration owner after exclusive bootstrap; Main then uses public snapshots and acknowledged mutations. No generic SQL/row RPC or second writer is introduced.
  • Credential persistence uses an explicit async string/boolean crypto port supplied by Main's native safeStorage adapter. Sync, MCP/plugin configuration, Nowledge and export consumers await real operations; wrapped storage, destination binding and cancellation remain enforced.
  • Sync connector and peer-pairing tokens retain their existing private files, legacy ciphertext, Linux secure-backend policy and generation-fenced pairing/connector startup.
  • Database security receives explicit path, metadata and native crypto ports; Main owns unlock and quit. A per-file lock holds through target wrapping, SQLCipher copy/reopen and metadata commit. Runtime rollback retains the original database and metadata on failure; cross-file power-loss recovery remains conditional Store work.
  • Session clearing uses one owner command for pending inputs, transcript projection and Tape reset. Runtime preparation/post-commit cleanup remain with the mutation coordinator. Retry truncation uses the atomic transcript range operation; replaced closure/row wiring is removed.
  • Sixteen selected settings fields use one application service with snapshots, acknowledged mutations and per-key presentation revisions. Agent display tools retain authorization and journal commitment while awaiting validated native mutation receipts.
  • Skill services receive explicit host directories and an async native directory capability. Selected business modules no longer import Electron; discovery, watcher ownership, rollback and scoped authorization remain in the same owner.
  • Shared database maintenance accepts six explicit data commands for verified backup files, named local/cloud backups, encryption enable/change/disable and live schema repair. Actual consumers use these commands; caller-supplied operation callbacks are removed. SQL, handles and transaction closures stay inside the owner.
  • Provider model facts and user overrides use the existing database adapters as their sole runtime storage. Removed both helpers' JSON defaults, the mutable store-factory setter and obsolete legacy-directory initialization. Legacy import stays in startup before database attachment. Main owns the native app-settings factory and supplies one application version; public routes, schema, secret metadata and defaults retain their existing behavior.
  • Main constructs the existing MCP/ACP bootstrap files from pure default builders before normalization, import and database attachment. MCP then uses its database adapter. ACP enabled/version/shared selection use the database; registry/manual/install legacy input is a copied read-only snapshot. Live Agent changes use the unified repository. Removed seven unused legacy helpers; rejected legacy mutation batches cannot partially change database settings. No extra writer, per-key IPC, schema or public route was introduced.
  • One maintenance operation owns pause, drain, dispatch, reopen, reconciliation and resume. Live repair uses the same exclusive admission as import/encryption. Backup and shutdown reject admission; shutdown is rechecked after drain, and preparation errors enter recovery. Ordinary ingress now shares one running/maintenance/failed state. Renderer and finite CLI requests drain before writer replacement, with a 30-second failure before dispatch. Queued startup work rechecks admission and its original cancellation signal; a canceled reply cannot release ownership of a still-running handler. Event watchers count only their initial database snapshot. Native presentation/status and identity-checked approval settlement remain available. Detached background effects, remaining configuration snapshots and native/window owners keep G4 open.
  • Main startup cancellation keeps immediate replies while a separate completion promise retains actual callback lifetime in the existing in-flight inventory. Maintenance cancels and drains the Main target, including canceled older runs, before pausing/recreating services or replacing the writer. Pending tasks never execute and release deduplication entries. A 30-second preflight failure restores ordinary admission without database replacement or duplicated services; shutdown is rechecked after the wait. Successful maintenance schedules background migrations again.
  • Shutdown closes request admission and background availability first. Actual startup callbacks drain after CLI/OAuth ingress stops; ordinary requests and completion-only maintenance ownership drain before writer close. Critical drain failures reject teardown before closing the writer or granting a terminal action. The two device dispatches that await shutdown do not wait on themselves; their CLI authorization remains counted. Interrupted maintenance cannot reopen/reconcile/resume, and failed-recovery cleanup starts only after its own lifetime is released. A late remote initialization is compensated. Existing validation, sender identity, cancellation and exclusive action claims remain enforced.
  • Normal build-generated Provider and ACP registry refreshes are retained. The large catalog diff is generated registry data.

MCP OAuth:

  • Main supplies the private credential path, secure async crypto and browser-open capability. Credential persistence, interactive/enterprise identity owners, SDK providers and actual connection/diagnostic consumers use this path; replaced native imports and default Store construction are removed.
  • One bounded owner queue serializes acknowledged writes and atomic binding-key moves. Initial decrypt is single-flight; RAM publication follows persistence, and encryption/rename failures preserve old RAM and disk. Twenty-four normal writes reserve eight control slots; stop rejects queued and pending native results without waiting for queue capacity.
  • Existing v1/v2 envelopes, bounds, memory-only fallback, Linux basic-text refusal, legacy native ciphertext and settings-window credential permissions remain compatible. V2 reads do not rewrite credentials or add another plaintext cache.
  • Synchronous loopback validation uses acknowledged public discovery metadata. Finalized identity uses one settings-owner CAS against server ID, generation, hash and endpoint. Profile edits retain concurrent unrelated profiles and reject replacement of the same profile.
  • Originating server/profile leases fence delayed refresh, browser, status and runtime effects. Plugin-owned connection changes use the existing supervisor through its probe, integrity/recovery, adapter/native launch and symmetric stop waits; canceled startup still cleans owned resources. Connection failures await OAuth classification and reject stale notifications.

Provider OAuth:

  • Main supplies Codex/Grok private paths, async string-only native crypto and browser-open capabilities. Both private Store/auth owners no longer import Electron or construct native defaults. Status/events, refresh, logout, global initialization and shutdown use these explicit dependencies.
  • Existing v1 encrypted/plain-file formats, native ciphertext, corrupt backups, fsync/rename and Provider file fallback remain compatible. Each file is bounded to 16 MiB and token payloads to 8 MiB; 24 normal mutations reserve eight control slots. Only pending reads coalesce, with no retained plaintext token cache. Failed deletion cannot acknowledge logout.
  • Grok synchronous token peeking is removed. The existing async fetch adapter supplies credentials to SDK and trusted direct requests. Original auth scopes and request cancellation are checked before dispatch and 401 refresh; interrupted owners cannot become API-key fallback. Ordinary refresh failure retains fallback.
  • Native wrapping, browser/device login, discovery, refresh and status effects are fenced against account replacement, logout, cancellation and shutdown. Status queries retry at most once on an observed account transition, and newer publications supersede delayed status reads.
  • Each auth owner admits at most 32 HTTP requests, with declared/streamed bodies bounded to 8 MiB. Existing timeouts and cancellation cover body reads as well as headers.

Validation:

  • MCP App acceptance: 964 checks across 34 affected files and 23 generated-catalog checks across two files pass, with native SQLite required. App and all affected MCP unit/new E2E types, normal/final builds, format/check, lint and i18n pass. Durable coverage includes creation bounds/release, owner/server/maintenance cancellation, an SDK that ignores cancellation, revoked consent, policy isolation, late native responses and single callback settlement. Generated Provider catalog changes are isolated in 5a79f205d.
  • Immutable ef4e8052a and the final candidate pass the same real model/MCP/saved-source/native-protocol/consent/relaunch workload (6.7/6.3 s). The public App routes hydrate an actual persisted model tool result; native responses retain CSP/permission headers. App tool calls, settings-window rejection, link allow/deny, shutdown with pending consent, saved-source reopen and source deletion all pass. The three final policy/stdio/App cases pass in 28.1 s. Browser launch is recorded at the shell boundary; external navigation and physical media permissions are not exercised. Evidence is .deepchat/rutis-g4-mcp-apps-acceptance/. No performance/resource recapture or speed claim.
  • Registry (one module), AppHost (five), the full McpService module graph (34), ToolService (204), actual Harness entry (350) and ProviderRuntime (131) import in ordinary Node with Electron/electron-store forbidden at build/runtime. This proves loading those graphs. Native protocol/session adapters remain in Main; G5 still must move the registry with its Store/source/permission authority and connect generation-fenced desktop domain operations through the private gateway. A composed headless backend and relocated writer remain open.
  • MCP runtime acceptance: 976 checks across 36 files pass, with native SQLite required. App and all affected MCP unit/new E2E types, the normal build, format/check, lint and i18n pass. Supplied home/version, absolute-home rejection and live proxy replacement have durable coverage; existing transport/auth/settings, environment bounds, child identity, deadlines and cancellation remain enforced. Generated ACP registry changes are isolated in 08ddc763f.
  • Immutable 3b3890dad and the candidate pass the same actual stdio MCP workload (7.3/7.5 s): public custom-Node selection, home/client identity, cwd and PATH precedence, minimal-environment secret exclusion, real tool calls, stop/start, graceful child cleanup and persisted relaunch. Candidate HTTP policy and stdio cases pass in 20.9 s; both Code Mode helper cases separately pass in 10.3 s. These are functional observations without a timing gate or speed claim. Evidence is .deepchat/rutis-g4-mcp-runtime-acceptance/.
  • McpClient (18 modules), ServerManager (19), ToolchainService (13), full ToolService (204), actual Harness entry (350) and ProviderRuntime (131) import in ordinary Node with Electron/electron-store forbidden at bundle and runtime. This does not establish native AppHost portability, a composed headless backend or relocated persistence owners. No performance/resource suite was repeated.
  • Integrated policy acceptance: 744 checks across 12 affected native files, 23 generated-model checks across two files and 16 ACP registry checks across two files pass. App and new owner-fixture/unit/E2E types, the normal/integrated app builds, format/check, lint and i18n pass. Coverage includes persistence errors, owner isolation, replacement/removal, ambiguity, current-policy ask enforcement under full access and the upstream Code Mode subagent ceilings. Native configuration, protocol, timeout and import guards remain enforced.
  • Frozen f0ca555fe and the final integrated app pass the same real HTTP MCP/persisted-policy/catalog/call/relaunch workload (13.2/13.3 s). Both comparison drivers select the owned test profile before loading the unchanged app entry because the old global native constructor preceded the app's profile override; exact entry bytes are restored afterward. Normal integrated startup separately passes four app cases in 29.3 s: Code Mode complete/held READY, Agent image/workspace reads and policy persistence/ambiguity/disabled records. No real user policy file is modified by the fixture. Evidence is .deepchat/rutis-g4-plugin-policy-acceptance/.
  • The policy owner, full 204-module ToolService, actual 350-module Harness entry and ProviderRuntime import in ordinary Node with Electron/electron-store forbidden. This establishes module loading; MCP runtime/native AppHost and a composed headless backend/writer remain open. No performance/resource capture, timing gate or speed claim was added. Policy implementation is 5c4557b7e; dev integration is 996efc3b0; normal generated catalogs are isolated in 1952466fd and 8cabd095e.
  • Agent Tool host acceptance: 689 checks across 14 affected native files and 23 generated-catalog checks across two files pass. App and new E2E types, normal/final app builds, format/check, lint and i18n pass. Durable cases cover injected roots/default workspace, approvals for unrelated files, metadata failures and a late image probe after cancellation. Existing symlink, journal, permission, vision preference, settings-window and Tool/Harness checks remain green. Seven obsolete Electron mocks are removed from pure Tool suites.
  • The same actual image metadata, workspace read and persisted-message reopen E2E passes on immutable 32f457ff7 and the final candidate (both 5.3 s). Four final app cases pass in 21.0 s, including background process feedback, Code Mode nested execution and held-READY helper shutdown. AgentToolManager's 126-module graph, the actual 350-module Harness entry and ProviderRuntime import in ordinary Node with Electron/electron-store forbidden. The composed headless backend/writer remains outside this module-loading claim. Evidence is .deepchat/rutis-g4-agent-tool-host-acceptance/. No performance/resource suite was repeated, timing gate added or latency/memory gain claimed.
  • Code Mode acceptance: 547 checks across 10 affected native files and 23 generated-catalog checks across two files pass. App and scoped native-adapter/manager/E2E types, normal/final app builds, format/check, lint and i18n pass. Startup reservation/cancellation/reuse, late-host compensation, actual nested callback drain, coalesced RSS reads, READY deadline and hard memory bounds remain covered. The generated catalog is isolated in f560f941e.
  • Immutable 12a73394f and the candidate pass the same nested execution, cell-global isolation and persisted-message reopen E2E; the final exact-assertion comparison is 6.4/5.2 s. Seven candidate app cases pass in 33.9 s, including held READY shutdown/helper exit/no subsequent model round, background execution lifecycle and native credential/database-maintenance shutdown holds. Code Mode, the actual 350-module Harness entry and ProviderRuntime import in ordinary Node with Electron/electron-store forbidden and no native imports; this does not establish a composed headless backend. The function frontend is exercised in the app; Codex store/yield/permission semantics remain covered by VM/manager suites without claiming an authenticated Codex app E2E. Evidence is .deepchat/rutis-g4-code-mode-acceptance/. No performance/resource suite was repeated, timing gate added or speed gain claimed.
  • Current background execution acceptance: 988 checks across 36 files pass, with native SQLite required. App/new regression/E2E types, normal/final application builds, format/check, lint and i18n pass. An isolated immutable source comparison confirms the 107 existing type errors in ported legacy fixtures have no new diagnostics; these fixtures are not claimed as typed passes. Background execution, Skill, ProviderRuntime and the actual 350-module Harness entry import in ordinary Node with Electron/electron-store forbidden and no native module imports. This does not establish a composed headless backend.
  • Matching exec/process and active-child shutdown/reopen E2Es pass on immutable edfb8ab43 (5.1/4.8 s) and the final candidate (5.3/5.0 s). Six final app cases pass in 34.3 s, including held helper startup shutdown with no command/subsequent model round, encrypted legacy unlock/rekey/disable and shutdown while native credential/database maintenance work is held. The held-start case exposed and verifies the early in-memory generation cancellation requirement. Evidence is .deepchat/rutis-g4-background-exec-acceptance/. No repeated performance/resource suite or speed claim. Full native Windows/Linux app behavior and remaining desktop/Store boundaries stay open.
  • Current installer acceptance: 244 checks across 20 files pass, with native SQLite required for the 16-file affected group. App/scoped types, normal/final application builds, format/check, lint and i18n pass. Installer, AgentSettings and the complete ProviderRuntime graph import in ordinary Node with Electron/electron-store forbidden. The generated Provider catalog is retained in 4810f55b2.
  • The immutable 3ede3013a app passes matching binary install/repair/reopen (4.2 s); the candidate passes (4.6 s). Six app scenarios pass in 34.8 s, including canceled repair shutdown with no late replacement/state commit, maintenance drain/recovery, failed repair preserving the old binary, registry refresh/shutdown and encrypted legacy unlock/rekey/disable. The maintenance scenario additionally passes public uninstall and its not_installed acknowledgement (5.2 s). Evidence is .deepchat/rutis-g4-acp-installer-acceptance/. No performance benchmark/resource recapture or speed claim. Synchronous extraction, Windows/Linux full native-app behavior, filesystem/SQL power-loss durability and remaining G4 host/writer dependencies remain open.
  • Current registry acceptance: 106 checks across eight affected files pass, including actual refresh drain, late header/body/icon responses, canceled-task reuse, late repository/Provider continuations, privacy/TTL/SVG and three-platform ordinary-file package validation. App/scoped regression types, normal build, format/check, lint and i18n pass. Registry, AgentSettings and the complete ProviderRuntime module graph import in ordinary Node with Electron/electron-store forbidden.
  • The immutable 45cbdf4c0 app passes the matching registry refresh/icon/reopen case (4.6 s); the migrated app passes (4.4 s). Four actual-app cases pass in 27.6 s, covering persisted/sanitized icons, unchanged legacy JSON, held-refresh graceful shutdown and late cache/Agent-write rejection, ACP prompt/child-output behavior and encrypted legacy unlock/rekey/disable. Evidence is .deepchat/rutis-g4-acp-registry-acceptance/. No performance suite/resource capture was repeated or speed gain claimed. This slice owns registry refresh; installation/prewarm and remaining host/writer dependencies keep G4 open.
  • Current ACP/Provider environment acceptance: 1,455 checks across 109 affected files pass (1,454 under Electron with native SQLite required, one real PTY case under ordinary Node). Generated-catalog checks also pass. App types, normal/final app builds, format/check, lint and i18n pass. Explicit absolute roots, original protocol version, PATH precedence, session restoration, bounded terminals and host-controlled TLS remain covered; obsolete private-helper spies/native mocks are removed.
  • Immutable a217ff4e5 passes the matching ACP protocol/structured-answer app case (7.1 s); the final build passes (7.7 s). The final three-case group passes in 14.6 s: ACP owning-prompt/child-output behavior, catalog/header bootstrap and held-refresh shutdown/reopen. ACP settings routes and encrypted legacy unlock/rekey/disable separately pass. All profiles are disposable. No performance suite/resource capture was repeated and no speed gain is claimed. Evidence is .deepchat/rutis-g4-acp-runtime-acceptance/. Generated catalog changes are isolated in 7aa6e8482.
  • Current Provider bootstrap acceptance: 1,165 checks across 81 affected files pass, including Provider HTTP/settings, Device, image-cache, startup/app boundaries and package-resource checks, with native SQLite required. App/scoped types, normal build, format, lint and i18n pass. Ordinary Node imports of Provider settings, Copilot HTTP and the AI SDK Provider pass with Electron and electron-store forbidden. Three-platform package fixtures validate the single catalog outside ASAR. Full six-platform package CI for this new head remains separate evidence.
  • The immutable 7fb11102f app passes matching catalog/header E2E (2.4 s); the migrated app passes (2.1 s). Four migrated app checks pass: catalog/header bootstrap, held-refresh drain/late-response fencing/graceful reopen, model persistence without legacy JSON rewrites, and encrypted legacy unlock/rekey/disable. Evidence is .deepchat/rutis-g4-provider-bootstrap-acceptance/. These are functional observations; no performance suite was repeated and no speed claim is made. Normal generated ACP registry refreshes are isolated in c3a7adbdc.
  • MCP/ACP acceptance: 637 checks across 43 affected files pass: 31 native configuration/migration files (386 checks), nine Node plugin files (201 checks), and three generated-catalog files (50 checks). Native SQLite is required for the native group. Modified settings/plugin/E2E scoped types pass. A temporary bundled probe constructs both settings classes and defaults with Electron and electron-store forbidden; this does not establish portability of the complete MCP/ACP runtime graph.
  • The same new MCP/ACP settings E2E passes on immutable ec82c12b4 (6.6 s) and the migrated application (6.9 s): disabled server/manual Agent changes, shared selection and global availability, graceful reopen, removal/reset and a second reopen. Legacy JSON bytes remain unchanged. All three selected app cases pass in 27.0 s, including encrypted database legacy unlock/rekey/disable and native MCP credentials/settings-window ownership. These are functional observations with no timing gate or speed claim; evidence is .deepchat/rutis-g4-mcp-acp-config-acceptance/.
  • The normal build refreshed the generated model catalog. Its data is isolated in commit 8d0210277; catalog checks pass. The initial combined test command used Electron as the executable for Node-only hook fixtures; those six subprocess failures pass under their correct Node runner. Native SQLite checks run separately under Electron. No production timeout or environment guard was relaxed.
  • Model persistence passes against the immutable 38306fcda artifact (6.9 s) and the migrated build (6.6 s): atomic custom-model/override save, graceful reopen, persisted values, reset/removal, another reopen and unchanged legacy JSON. All five selected app cases pass in 43.8 s, including launch, obsolete-plugin repair, plugin initialization failure and encrypted legacy unlock/rekey/disable. These are functional observations with no timing gate or speed claim; evidence is .deepchat/rutis-g4-provider-config-acceptance/.
  • 7 real-app scenarios pass in 39.1 s in owned disposable profiles: launch/close; encryption/legacy unlock/wrong-password recovery/rekey/disable; built-CLI Provider-list with backup/import/repair/relaunch; concurrent maintenance rejection; delayed credential drain; quit with a held native credential; quit with held database maintenance. The last two close the window while work remains owned, release it through the still-live Main connection, exit with code zero and reopen without an interrupted secret or encryption commit. No external account is contacted.
  • The matching baseline launch/close and encrypted-reopen cases pass in 14.8 s (3.7/10.9 s); final samples are 7.7/10.7 s. These whole-scenario timings include startup and presentation and have no timing gate or speed claim. Accepted app evidence is .deepchat/rutis-g4-shutdown-acceptance/final-e2e.log and final-results/; earlier driver diagnostics remain retained.
  • App and scoped configuration/gate/E2E types, the normal build, format/check, lint and i18n pass. The existing large legacy dispatcher fixture has unrelated type drift outside these scoped type checks; its runtime suite passes. The E2E fixture retains the launched child handle and recognizes an already completed exit-zero process as graceful; measurement failures and forced-close handling retain their existing outcomes. Normal generated catalogs remain retained. Evidence and remaining scope are in the live plan.
  • Request ownership retains 616 checks across 36 files; maintenance commands retain 158 native checks across nine files; the preceding dev integration passes 217 main checks, 291 renderer checks and four app scenarios. These accepted checkpoints remain documented with their exact CI barriers and artifacts.
  • Provider OAuth acceptance retains 1,213 checks across 79 files, final 150 checks across nine files, and the four-launch native/plaintext compatibility, cancel, durable logout and signed-out relaunch E2E (12.0 s). Evidence remains in .deepchat/rutis-g4-provider-oauth-acceptance/.
  • MCP acceptance retains 657 checks across 33 files and 3 real-app E2Es in 34.2 s. Its supplemental selection recorded 13 passes, two skips and an unmodified Provider headers fixture failure waiting for the absent disabled-providers-toggle; that failure/artifacts remain recorded and are not represented as passing OAuth acceptance.

Settings behavior:

BEFORE
new event v2 -> UI value v2
late read v1 -> UI value v1

AFTER
new event v2 -> UI value v2
late read v1 -> ignore older keys; hydrate untouched keys

Performance policy:

  • Shared Memory CI timing overruns are reports through DEEPCHAT_MEMORY_PERF_REPORT_ONLY=1. Correctness, native operations, finite measurements, runtime/ABI identity, workload/queue bounds and timeouts still block; no continue-on-error hides failures.
  • Every slice requires relevant tests and matching functional app E2E. Fixed-device resource comparisons are selected for material process, IPC, batching or storage-path changes, or an explicit performance objective. Ordinary async port extraction does not require another whole-process capture.
  • Start a structural resource comparison with one representative affected workload. Five paired samples apply to explicit performance adoption decisions. For a concrete suspected regression, permit at most one predeclared confirmation batch; retain all samples and resolve reproducible material regressions. If inconclusive, record the uncertainty and stop measuring. Further measurement requires changed code/workload or concrete new evidence; CI timing noise does not block structural extraction. Never rerun CI until timing happens to pass. No uncertain/noise-level result establishes a speed claim.
  • G3 retains all 52 successful app runs and the original loaded-control failure. Its prespecified independent five-pair confirmation and all ten pooled pairs pass the frozen resource rules. Full sample groups, immutable artifacts and resource/protocol limits remain in the live plan; this is not a Rust CPU speedup claim.

Limits:

  • Native OAuth credential compatibility is verified on macOS arm64. Real Windows/Linux vaults, external identity-provider/browser flows, physical suspend/resume and signed full-app fault scenarios remain unverified locally.
  • Six-platform packages execute the production Memory runtime smoke; they do not establish those full-app native scenarios. Local process-tree evidence uses unpackaged builds and records shared/native costs.
  • G5 must move the cohesive shared owner without a second writer and transport legal large credential envelopes through bounded frames. No gateway-limit increase, truncated result, generic SQL/row RPC or automatic fallback is introduced.

@coderabbitai

coderabbitai Bot commented Oct 25, 2026

Copy link
Copy Markdown
Contributor

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

  • Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

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.

1 participant