J3 and 1M
Use the same pinned Node lifecycle around two existing customer-local browser engines without copying either product’s intelligence into the SDK.
J3: pinned browser body
J3 injects the public transport at the seam around its paired backend channel and existing claimed lifecycle runner. Its Rust body remains responsible for pairing behavior, vault access, local Chrome/CDP control, final-submit confirmation, receipts, and audit. The legacy route remains the default; the Node route is opt-in for test work.
- Declare
com.jobsjobsjobs/local_hybrid@1on the paired body. - Provision a zero-reward
customer_localtest job pinned to that node. - Enter the existing runner through the generic adapter.
- Keep all J3 graph decisions and CDP actions below that seam.
The default-off J3 brain connector has completed a cross-host brain → isolated Core staging → customer-local Rust lifecycle. The application observed the exact queued, running, and completed projections, then received a structured receipt and proof reference. The final network run used the deterministic non-CDP lifecycle body; separate no-submission checks cover the production CDP body. This verifies interoperability in test mode, not production readiness.
1M: pinned local executor
1M’s adapter targets the same pinned assignment mode around its existing local browser executor. It must preserve the normal extension/background path and obtain seller authorization before browser I/O. Browser credentials, sessions, seller policy, and executor implementation stay local.
The staging compatibility check compiled a bounded seller-approved script through 1M’s existing DSL parser with dry-run authority. It completed the public lifecycle without invoking the browser runner or mutating a marketplace.
The final opt-in extension controller maps configure, run, cancel, status, and disconnect into the existing browser-runner seam. Its strict compile, production WXT build, full test suite, and Playwright checks pass; production customer traffic remains disabled.
Shared rules
- Node mode is opt-in; do not replace the existing product path.
- Match the exact work ID, revision, capability, node, and local authorization.
- Map only lifecycle events. Do not map CDP commands or product domain objects into Node core.
- Abort at a safe boundary after cancellation, revocation, or authorization failure.
- Keep private graphs, secrets, sessions, and final product policy in the wrapper.