[WRONG BRANCH] promote dev onto main for v2.38.0

AGENTS.md

@@ -305,8 +305,11 @@ repository CI; a maintainer has to — so the gate never disproves it; a new
 push still resets every box. A disproved claim unticks the matching box and
 keeps the PR a draft.
 Authors with repository push permission skip the ancestry heuristic only. As with approval requirements in
-[`MAINTAINERS.md`](./MAINTAINERS.md), this is enforced by convention until
-branch protection is configured.
+[`MAINTAINERS.md`](./MAINTAINERS.md), the ancestry heuristic is a CI check
+rather than a branch rule. The branches themselves are protected: `dev`,
+`main`, and `preview` each carry an active ruleset requiring a reviewed pull
+request and blocking force-pushes and deletion, so a direct push to `dev` is
+rejected regardless of `--no-verify`.
 
 [`MAINTAINERS.md`](./MAINTAINERS.md) is authoritative for review and merge
 policy (approvals, CI requirements, security review, promotion). This file

MAINTAINERS.md

@@ -52,8 +52,8 @@ when a maintainer steps down.
   a new push still resets every box. A disproved claim unticks the matching
   box and keeps the PR a draft.
   Authors with repository push permission skip the ancestry heuristic only. As
-  with the approval requirement above, this is enforced by convention until
-  branch protection is configured (see the note under the change log).
+  with the approval requirement above, this part is enforced by convention;
+  the ruleset does not check ancestry (see the note under the change log).
 - A pull request requires approval from at least one maintainer and successful required CI checks
   before merge.
 - Authors do not approve their own pull requests.
@@ -160,11 +160,21 @@ Adding or removing a maintainer requires:
   and release automation keep the two owners already listed for those paths, so
   this addition does not widen the review surface for them.
 
-  CODEOWNERS requests reviews rather than enforcing them — no branch protection
-  rule is configured on this repository, so code-owner approval is a convention
-  here, not a gate. The same is true of the approval requirement in the review
-  and merge policy above. Widening the security boundary, or enforcing either
-  of these through branch protection, is a separate decision.
+  Code-owner approval and the maintainer-approval requirement above are both
+  enforced, not conventions. `dev`, `main`, and `preview` each carry an active
+  repository ruleset — the classic `/branches/{branch}/protection` endpoint
+  returns 404 for them, which is why this file long described the repository as
+  unprotected. `Protect dev` (id 20763889) requires a pull request with one
+  approving review, code-owner review, and extra approval for unattributed
+  changes, and it blocks deletion and non-fast-forward pushes. Allowed merge
+  methods are merge and squash; rebase merges are off.
+
+  The one carve-out is that the `maintain`/`admin` repository role holds a
+  `pull_request` bypass, so an owner can merge without the approval the rules
+  otherwise require. That is a bypass, not an exemption: "Authors do not approve
+  their own pull requests" above still governs, and an owner who uses the bypass
+  should record it on the pull request rather than leave it to be inferred from
+  a merge timestamp. Widening the security boundary is a separate decision.
 
 ## Security reports
 

bin/ocx.mjs

@@ -23,6 +23,10 @@ import {
 } from "../src/update/npm-cache-preflight.mjs";
 import { handoffWindowsTrayForUpdate, planWindowsTrayUpdate } from "../src/update/tray-update-plan.mjs";
 import { bootRestoreProbe, transactionalNpmUpdate } from "../src/update/transactional-install.mjs";
+import {
+  CODEX_CLI_VERSION_MANAGER_ROOT_ENV_SLOTS,
+  isCodexCliUpdateInspectionArgv,
+} from "../src/update/codex-cli-update-launch-policy.mjs";
 
 const PKG = "@bitkyc08/opencodex";
 const require = createRequire(import.meta.url);
@@ -155,10 +159,9 @@ function runNpmSelfUpdate() {
     process.platform === "win32" ? trayInstallState() : { installed: false, running: false },
   );
   /**
-   * Refresh the existing service without re-registering it. `service repair` discovers
-   * the installed backend itself and, on Windows scheduler installs, rewrites the wrapper
-   * assets and restarts the existing task without `schtasks /create` — the elevation a
-   * non-admin `ocx update` does not have.
+   * Refresh the existing service in place. `service repair` discovers the installed backend;
+   * healthy Windows scheduler registrations avoid `schtasks /create`, while stale definitions
+   * may be re-registered and require elevation.
    */
   function serviceRefreshArgs() {
     return [launcher, "service", "repair"];
@@ -290,7 +293,8 @@ function runNpmSelfUpdate() {
         }
       }
       if (needDirectStart) {
-        // A repair needs no elevation, but it can still fail — or exit 0 while leaving
+        // Repair normally avoids elevation for a healthy registration, but a stale Windows
+        // scheduler definition can require it. It can also fail — or exit 0 while leaving
         // a non-viable manager. Fall back to a direct detached proxy start so the
         // update never leaves the user without a running proxy.
         console.warn(
@@ -468,7 +472,7 @@ function fail(msg) {
   process.exit(1);
 }
 
-function resolveBun() {
+function resolveBun({ allowInstall = true } = {}) {
   // Keep direct npm-launcher starts aligned with durable service/shim installs:
   // a valid explicit runtime must win even when the bundled dependency exists.
   const override = process.env[BUN_OVERRIDE_ENV]?.trim();
@@ -493,7 +497,7 @@ function resolveBun() {
   // Lazy fallback: --ignore-scripts (or a failed postinstall) leaves the
   // ~450-byte placeholder stub. Run the bun package's own installer once.
   const installJs = join(bunDir, "install.js");
-  if (existsSync(installJs)) {
+  if (allowInstall && existsSync(installJs)) {
     const r = spawnSync(process.execPath, [installJs], { stdio: "inherit" });
     if (r.status === 0) bin = findBunBinary(bunDir);
   }
@@ -512,14 +516,20 @@ if (updateHelpRequested) {
   process.exit(0);
 }
 
+const codexCliUpdateInspection = isCodexCliUpdateInspectionArgv(process.argv);
+if (codexCliUpdateInspection && typeof process.versions.bun === "string") {
+  console.error("opencodex: codex-cli-update inspection must use the published Node launcher.");
+  process.exit(1);
+}
+
 if (process.argv[2] === "update" && isNodeModulesInstall() && !isBunGlobalInstall()) {
   runNpmSelfUpdate();
 }
 
 // #1849 boot probe: a prior update that lost power (or double-faulted) mid-swap leaves a
 // backup sibling and a broken live tree. Restore before anything tries to run from the
 // broken tree; reap stale backups once the live tree verifies healthy.
-if (isNodeModulesInstall() && !isBunGlobalInstall()) {
+if (!codexCliUpdateInspection && isNodeModulesInstall() && !isBunGlobalInstall()) {
   try {
     const probe = bootRestoreProbe(resolve(here, ".."));
     if (probe.action === "restored") {
@@ -530,7 +540,7 @@ if (isNodeModulesInstall() && !isBunGlobalInstall()) {
   } catch { /* the probe must never block launch */ }
 }
 
-const bunRuntime = resolveBun();
+const bunRuntime = resolveBun({ allowInstall: !codexCliUpdateInspection });
 const bun = bunRuntime.path;
 
 // Run the Bun child asynchronously and FORWARD termination signals to it, then wait
@@ -554,20 +564,69 @@ const bun = bunRuntime.path;
 // interpolation and provider settings legitimately read the project environment.
 const preBunAnthropicSlots = ["ANTHROPIC_API_KEY", "ANTHROPIC_AUTH_TOKEN", "ANTHROPIC_BASE_URL"]
   .filter(name => typeof process.env[name] === "string" && process.env[name] !== "");
+// A configured CODEX_CLI_PATH may legitimately be cwd-relative (`./tools/codex`), which the
+// ordinary runtime resolver accepts. Inspection only trusts absolute local paths, so capture
+// the absolute form here, in the launcher, while the original cwd is still authoritative;
+// resolving it later would silently reinterpret it against a different working directory.
+//
+// A bare command with no separator (`codex`) is NOT a relative path: the runtime resolver
+// deliberately hands those to executable lookup along PATH. Rewriting it to `<cwd>/codex`
+// would make the inspector treat it as an explicit path and stop searching PATH entirely.
+const configuredCodexCliPath = typeof process.env.CODEX_CLI_PATH === "string" && process.env.CODEX_CLI_PATH !== ""
+  ? process.env.CODEX_CLI_PATH
+  : null;
+const preBunCodexCliPath = configuredCodexCliPath !== null
+    && (configuredCodexCliPath.includes("/") || configuredCodexCliPath.includes("\\") || /^[A-Za-z]:/.test(configuredCodexCliPath))
+  ? resolve(configuredCodexCliPath)
+  : configuredCodexCliPath;
+const preBunPath = typeof process.env.PATH === "string" ? process.env.PATH : null;
+const preBunPathExt = typeof process.env.PATHEXT === "string" ? process.env.PATHEXT : null;
+const preBunCodexCliManagerRoots = Object.fromEntries(
+  CODEX_CLI_VERSION_MANAGER_ROOT_ENV_SLOTS.flatMap(name => {
+    const value = process.env[name];
+    return typeof value === "string" && value !== "" ? [[name, value]] : [];
+  }),
+);
 const launchProof = randomBytes(32).toString("base64url");
 const launchContext = JSON.stringify({
   version: 1,
   proof: launchProof,
   anthropicEnvSlots: preBunAnthropicSlots,
+  codexCliInspectionEnv: codexCliUpdateInspection ? {
+    codexCliPath: preBunCodexCliPath,
+    path: preBunPath,
+    pathExt: preBunPathExt,
+    managerRoots: preBunCodexCliManagerRoots,
+    configDir: configDir(),
+  } : null,
 });
+// The inspection snapshot above already carries PATH, PATHEXT, and the manager-root slots as
+// proof-bound values, and `inspectCodexCliInstall` reads them from that snapshot rather than
+// from the live environment. Inheriting them again would spend the 32,767-character Windows
+// environment block twice, so a large-but-valid shell environment could stop the Bun child
+// from spawning and fail the command before it reports anything. Drop the duplicates for the
+// one-shot inspection launch only; every other launch inherits the environment unchanged.
+// Windows environment names are case-insensitive, but this spread produces an ordinary
+// case-sensitive object, and a real Windows environment commonly spells the variable `Path`.
+// Deleting only the canonical upper-case spelling would silently leave that copy behind and
+// reintroduce the duplication this block exists to prevent, so match on the lowercase form.
+const inheritedEnv = { ...process.env };
+if (codexCliUpdateInspection) {
+  const snapshotted = new Set(
+    ["PATH", "PATHEXT", ...CODEX_CLI_VERSION_MANAGER_ROOT_ENV_SLOTS].map(name => name.toLowerCase()),
+  );
+  for (const name of Object.keys(inheritedEnv)) {
+    if (snapshotted.has(name.toLowerCase())) delete inheritedEnv[name];
+  }
+}
 const child = spawn(bun, [cliPath, `${NODE_LAUNCH_PROOF_PREFIX}${launchProof}`, ...process.argv.slice(2)], {
   stdio: "inherit",
   // A headless Windows parent (Task Scheduler, dashboard restart, shortcut) has no
   // console to inherit. Without this flag Windows allocates a visible console for
   // the long-running Bun child, and closing that window kills the proxy (#1236).
   windowsHide: true,
   env: {
-    ...process.env,
+    ...inheritedEnv,
     [NODE_LAUNCH_CONTEXT_ENV]: launchContext,
     [BUN_RUNTIME_SOURCE_ENV]: bunRuntime.source,
     [BUN_RUNTIME_PATH_ENV]: bunRuntime.path,

devlog/_plan/260831_aside_client_and_integrations_ux/000_plan.md

@@ -0,0 +1,46 @@
+# Aside client + Integrations UX repair
+
+Unit opened 2026-08-31. Two outcomes travel together because they land on the
+same page: Aside becomes an export/integration client, and the Integrations
+("연결") surface stops flooding itself with rollback rows.
+
+They are one unit rather than two because the Aside work ADDS a twelfth card to
+a page that is already too crowded to absorb one. Shipping the client first
+would make the page measurably worse before it got better.
+
+## The two problems
+
+**Aside is unsupported.** Aside is a Chromium fork with a built-in browser
+agent. Its custom-provider catalog lives at `~/.aside/u/<accountId>/models.json`
+and its schema is the one Pi reads. The user on this machine already wired
+opencodex into it BY HAND: the live file carries a `providers.opencodex` block
+with 24 routed models, `api: "openai-completions"`, and
+`apiKey: "opencodex-loopback"` — byte-identical to what `buildPiClientConfig`
+emits. A hand-maintained integration is the strongest possible argument that
+the client belongs in the registry.
+
+**The Integrations page floods.** The rollback journal renders up to 50 rows,
+each with its own border, at the bottom of the overview AND again on every file
+client tab. The user's words were "로그 밑에 막 다닥다닥 뜨는 히스토리" — the
+per-row borders are literally what produces that texture.
+
+## Work phases
+
+| Phase | Doc | Deliverable |
+|---|---|---|
+| wp1 | this unit | Research and roadmap (docs only) |
+| wp2 | 010 | Aside export client + integration registry |
+| wp3 | 020 | Aside GUI surface, marks entry, nine locales |
+| wp4 | 030 | Rollback surface redesign |
+| wp5 | 040 | Brand marks for the nine clients showing a monogram |
+| wp6 | 050 | Stacked PR chain |
+
+Research docs: 001 (Aside contract), 002 (registration checklist),
+003 (Integrations UX diagnosis), 004 (brand mark provenance).
+
+## Ordering constraint
+
+wp4 and wp5 do not depend on wp2/wp3, and wp3 depends on wp2. The stack is
+therefore not a single line: the Aside pair (wp2 then wp3) and the page repair
+pair (wp4, wp5) are independent chains that both branch off `dev`. wp6 puts
+them in review order.