feat(native): Linux support, phase 1 — compile & boot

[tlgimenes]

Summary

Phase 1 of Linux support for the desktop app: the port compiles, boots, signs in, and runs agents on Linux. Full plan (18 work items across 3 phases) lands here as apps/native/docs/linux-support-plan.md. Phases 2 (org-FS mount) and 3 (release pipeline, AppImage on the update channel, web download surface) follow separately.

Scope decision: v1 Linux distribution is AppImage + the existing tauri updater channel. AUR/apt/COPR deferred; Flatpak/Snap out of scope.

Every change is cfg/OS-gated — macOS runtime behavior and produced artifacts are unchanged.

What's here

• TLS trust — the Linux webview trusts the local control origin via a WebKitGTK per-host certificate exception instead of an OS trust store (AppImage has no postinst). Ships behind an opt-in DECOCMS_LINUX_SECURE_ORIGIN, since a fatal boot path on Linux has no cask to reinstall from; show_boot_failure names the variable.
• Child CA bundle — spawned CLIs get a system+local bundle via SSL_CERT_FILE, fail-closed: SSL_CERT_FILE replaces the root store, so nothing is exported unless a system bundle was found. Otherwise codex would silently lose the public internet.
• org-FS — gated off (Linux mount lands in Phase 2), degrading to the already-supported empty org/, with a DECOCMS_DISABLE_ORG_FS runtime escape.
• Updater — gated on the APPIMAGE env var. The plugin rewrites $APPIMAGE in place and has no such guard, so a dev/deb/rpm binary would overwrite itself.
• Build — rclone fetch learns the Linux triples (without it the bundler fails on the missing externalBin); new tauri.linux.conf.json5 overlay targeting appimage; the PNG sizes Linux bundlers need.
• boot-smoke — AppImage extract-and-launch path, plus an assertion that rclone is staged beside the binary. Also pins the tauri CLI so the smoke validates an artifact from the same bundler the release ships.
• CI — ubuntu legs for rust-checks, tauri-build and contract-suite; the root test runner now discovers apps/native/scripts, which no workflow executed before.
• Keychain — backend choice (debug && macos) separated from namespace choice (debug), pinned by a four-quadrant test instead of resting on an incidental cfg constant.

Testing

macOS gates green: cargo test --workspace 1092 pass / 0 fail, cargo clippy --workspace --all-targets -D warnings clean, cargo fmt --check clean, bun run check / lint / fmt:check / knip clean.

Known verification gap: no cfg(target_os = "linux") code compiles on a macOS host — roughly ten cfg blocks plus all of webview_trust.rs. It was audited by hand against vendored crate sources (webkit2gtk =2.0.2 matches wry's exact pin; allow_tls_certificate_for_host and connect_load_failed_with_tls_errors are both gated on v2_6, and the signal's closure signature matches). The new ubuntu legs in this PR are the first real check — expect iteration.

Four tests never execute on macOS and rely on the ubuntu leg: the two in webview_trust, env_path::unix::tests::fallback_dirs_use_linux_locations, and a cfg(linux) assertion in dev.rs.

🤖 Generated with Claude Code

---

Summary by cubic

Adds phase 1 Linux support for the desktop app: AppImage builds compile, boot, sign in, and run agents on Linux. macOS behavior and shipped artifacts are unchanged.

• New Features

  • Linux TLS trust via a WebKitGTK per-host exception; opt-in with DECOCMS_LINUX_SECURE_ORIGIN.
  • Child processes get SSL_CERT_FILE with a system+local CA bundle; fails closed if no system store is found.
  • Org filesystem stays off on Linux; escape hatch DECOCMS_DISABLE_ORG_FS.
  • Updater runs only when APPIMAGE is set; login opens via xdg-open; PATH repair and the ripgrep hint include Linux.
  • Preview host observer added to enable preview iframes in the Linux webview.
  • Token store namespaces dev/release on all OSes and uses the OS credential service (macOS Keychain, Linux Secret Service).

• Build & CI

  • Added tauri.linux.conf.json5 targeting AppImage and required icons; rclone fetch includes Linux slugs; AppImage bundling resolves rclone inside the mounted squashfs.
  • Boot smoke supports AppImage via AppRun, pins @tauri-apps/cli, requests software rendering for headless Linux, reliably dumps stdout/stderr, and no longer gates on public CDN egress.
  • New Ubuntu legs for rust-checks, tauri-build, and contract-suite; split Linux rust-checks into separate lint/test runners, free runner disk, cap link parallelism, run bounded steps, and chunk local-api tests across processes.
  • Process-group robustness: correct group-liveness probe with pgrep -g; restore the original anchor enumeration; refuse group 0, skip own pid, verify leadership before kill -<pid>; extend reap deadlines; live-group tests and the cleanup-deadline test are excluded only on GitHub Ubuntu runners (confirmed passing on real Linux).
  • macOS-only e2e suites scoped to macOS; unit runner includes apps/native/scripts; pinned webkit2gtk to =2.0.2 with v2_6 APIs; added CI aggregator jobs to preserve required check names with the new OS matrix.

^{Written for commit 913a263. Summary will update on new commits.}

[cubic-dev-ai]

15 issues found and verified against the latest diff

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="apps/native/crates/local-api/src/sandbox/org_mount.rs">

<violation number="1" location="apps/native/crates/local-api/src/sandbox/org_mount.rs:47">
P2: On Linux, gitless agents still run directly in the raw `<app_root>/orgs/<slug>` directory even though org-fs is disabled, so writes intended for organization storage can silently land in unsynchronized local state instead of using the empty-org degradation. The gitless cwd selection could honor the same platform gate and use the documented fallback when no mount stack is active.</violation>
</file>

<file name="apps/native/crates/local-api/src/setup/dev.rs">

<violation number="1" location="apps/native/crates/local-api/src/setup/dev.rs:785">
P2: Upgrading a Linux installation with a live persisted dev server can permanently block the next start: the old sidecar stores the `ps comm` name, while this code observes an absolute `/proc/<pid>/exe` path and the exact identity comparison refuses to reap it. A migration or compatibility comparison for pre-path identities would preserve safe cleanup across upgrades without weakening the fail-closed behavior for genuinely different processes.</violation>
</file>

<file name="apps/native/crates/local-api/src/routes/intercept/sandbox_lifecycle.rs">

<violation number="1" location="apps/native/crates/local-api/src/routes/intercept/sandbox_lifecycle.rs:148">
P2: Listing agent sessions now trusts preview hosts for stopped or failed sandboxes even though their URLs are discarded afterward. Because the WebKit exception set is append-only, historical records can grow that set and enqueue unnecessary GTK work; the host should be observed only when a running preview URL is actually returned.</violation>
</file>

<file name="apps/native/src-tauri/src/setup.rs">

<violation number="1" location="apps/native/src-tauri/src/setup.rs:77">
P1: Enabling `DECOCMS_LINUX_SECURE_ORIGIN=1` makes the Linux secure-mode self-test fail before it can report success: its hard-coded HTTP/localhost preview probes no longer match the HTTPS real-domain listeners and navigation allow-list, and the secure self-test origin is absent from the Tauri capability URLs. The secure self-test path would need to derive its control/preview URLs and capability scope from the selected origin, or the opt-in should not apply to self-test mode.</violation>
</file>

<file name="apps/native/scripts/boot-smoke.ts">

<violation number="1" location="apps/native/scripts/boot-smoke.ts:208">
P2: A repeat Linux smoke run can validate an old AppImage after Linux bundle configuration or the bundled rclone changes, because this new artifact-reuse path does not track those inputs. Including the Linux overlay and sidecar-fetch inputs in the freshness set would keep the smoke pointed at the artifact produced from current sources.</violation>
</file>

<file name="apps/native/src-tauri/src/env_path.rs">

<violation number="1" location="apps/native/src-tauri/src/env_path.rs:47">
P2: Linux launches with an unset `SHELL` cannot repair PATH on systems without `/bin/bash`, because the fallback probe fails before reading the login environment. Using `/bin/sh` here would provide the required POSIX behavior without making PATH repair depend on Bash being installed.</violation>
</file>

<file name="apps/native/src-tauri/src/webview_trust.rs">

<violation number="1" location="apps/native/src-tauri/src/webview_trust.rs:94">
P2: A preview iframe can still fail its first HTTPS load even though the observer fired: this call queues `allow_host` on GTK without an acknowledgement, while `preview_url_for` immediately returns the URL. If WebKit starts the iframe before the queued callback registers the exception, the subframe has no recovery signal and remains broken until another navigation or reload.</violation>

<violation number="2" location="apps/native/src-tauri/src/webview_trust.rs:112">
P2: A trust-dispatch failure permanently disables retries for that preview host: it is marked `granted` before `with_webview`, and subsequent observer calls return without attempting registration again. A transient dispatch, window, or certificate-read failure can therefore leave that sandbox's iframe unable to load for the rest of the process.</violation>
</file>

<file name="apps/native/e2e/helpers.ts">

<violation number="1" location="apps/native/e2e/helpers.ts:139">
P2: In this Linux phase the keychain suite is permanently locked to macOS via `process.platform !== "darwin"`, so the Secret Service/keychain path gets zero coverage on Linux — even on a dev box where gnome-keyring-daemon is running and the store would work. Consider gating on an env probe/opt-in (e.g. `DECOCMS_E2E_KEYCHAIN=1`) instead of a hardcoded platform check, so Linux coverage can be enabled without editing source once CI stands up a keyring daemon.</violation>
</file>

<file name=".github/workflows/native.yml">

<violation number="1" location=".github/workflows/native.yml:166">
P2: PR required checks can stop matching after this matrix conversion: GitHub reports matrix children with the matrix suffix rather than the old single-job check name. Retaining an aggregate job with the existing required name, or explicitly updating branch protection to require both matrix checks, would preserve the gate and ensure Linux is actually required.</violation>

<violation number="2" location=".github/workflows/native.yml:630">
P3: The Linux smoke launches the extracted AppImage's `AppRun`, not `squashfs-root/usr/bin/deco` directly; keeping this comment accurate will avoid misleading failure diagnosis when WebKit/AppRun environment setup is involved.</violation>
</file>

<file name="apps/native/src-tauri/src/local_tls.rs">

<violation number="1" location="apps/native/src-tauri/src/local_tls.rs:60">
P3: Linux documentation builds now have broken `ensure_trusted` intra-doc links because this platform gate removes the target item. A platform-neutral link or cfg-specific documentation would keep Linux rustdoc warning-free.</violation>

<violation number="2" location="apps/native/src-tauri/src/local_tls.rs:327">
P2: Linux child TLS can fail after a truncated or stale `ca-cert.pem`: `ensure` may still build the leaf from the valid key, but this new bundle path appends the corrupted file instead of the CA actually used to sign it. Keeping the persisted CA certificate validated/synchronized with the key before building the bundle would avoid booting with an unusable child trust store.</violation>

<violation number="3" location="apps/native/src-tauri/src/local_tls.rs:361">
P2: A non-empty but non-PEM system file is treated as a valid root store, so the generated replacement bundle can contain no public roots and break the child’s public HTTPS connections. Validating that the candidate contains parseable certificates (or skipping/failing it) would preserve the superset guarantee.</violation>
</file>

<file name="apps/native/crates/upstream/src/login.rs">

<violation number="1" location="apps/native/crates/upstream/src/login.rs:317">
P3: On Linux the added xdg-open path still uses `.spawn().map(|_| ())`, so a non-zero xdg-open exit (no browser, no DISPLAY) is reported as success. The new doc comment's soft-fail promise only holds when the binary itself is missing; in the common headless/bare-session case the caller logs "system browser launched" and the user hangs until the 5-min loopback timeout. Consider waiting on and checking xdg-open's exit status so the soft-fail (log URL) path in perform_interactive_login actually triggers, or capture stderr for the log.</violation>
</file>

<sub>Tip: cubic can generate docs of your entire codebase and keep them up to date. Try it here.

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: Enabling DECOCMS_LINUX_SECURE_ORIGIN=1 makes the Linux secure-mode self-test fail before it can report success: its hard-coded HTTP/localhost preview probes no longer match the HTTPS real-domain listeners and navigation allow-list, and the secure self-test origin is absent from the Tauri capability URLs. The secure self-test path would need to derive its control/preview URLs and capability scope from the selected origin, or the opt-in should not apply to self-test mode.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/src-tauri/src/setup.rs, line 77:

<comment>Enabling `DECOCMS_LINUX_SECURE_ORIGIN=1` makes the Linux secure-mode self-test fail before it can report success: its hard-coded HTTP/localhost preview probes no longer match the HTTPS real-domain listeners and navigation allow-list, and the secure self-test origin is absent from the Tauri capability URLs. The secure self-test path would need to derive its control/preview URLs and capability scope from the selected origin, or the opt-in should not apply to self-test mode.</comment>

<file context>
@@ -35,6 +35,48 @@ pub enum SetupError {
+    let mut origin = control_origin::current(selftest);
+    #[cfg(target_os = "linux")]
+    {
+        origin.secure = linux_secure_origin_enabled();
+    }
+    origin
</file context>

[cubic-dev-ai]

P2: On Linux, gitless agents still run directly in the raw <app_root>/orgs/<slug> directory even though org-fs is disabled, so writes intended for organization storage can silently land in unsynchronized local state instead of using the empty-org degradation. The gitless cwd selection could honor the same platform gate and use the documented fallback when no mount stack is active.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/local-api/src/sandbox/org_mount.rs, line 47:

<comment>On Linux, gitless agents still run directly in the raw `<app_root>/orgs/<slug>` directory even though org-fs is disabled, so writes intended for organization storage can silently land in unsynchronized local state instead of using the empty-org degradation. The gitless cwd selection could honor the same platform gate and use the documented fallback when no mount stack is active.</comment>

<file context>
@@ -39,6 +39,30 @@ use crate::process_group::ProcessGroupChild;
+/// Everything below — `rclone nfsmount`, the BSD `mount` table, `umount -f` —
+/// is macOS-shaped. Porting the FUSE path flips this to
+/// `|| cfg!(target_os = "linux")`.
+const PLATFORM_SUPPORTED: bool = cfg!(target_os = "macos");
+
+/// Set to anything to force the unsupported-platform path.
</file context>

[cubic-dev-ai]

P2: Upgrading a Linux installation with a live persisted dev server can permanently block the next start: the old sidecar stores the ps comm name, while this code observes an absolute /proc/<pid>/exe path and the exact identity comparison refuses to reap it. A migration or compatibility comparison for pre-path identities would preserve safe cleanup across upgrades without weakening the fail-closed behavior for genuinely different processes.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/local-api/src/setup/dev.rs, line 785:

<comment>Upgrading a Linux installation with a live persisted dev server can permanently block the next start: the old sidecar stores the `ps comm` name, while this code observes an absolute `/proc/<pid>/exe` path and the exact identity comparison refuses to reap it. A migration or compatibility comparison for pre-path identities would preserve safe cleanup across upgrades without weakening the fail-closed behavior for genuinely different processes.</comment>

<file context>
@@ -782,10 +782,38 @@ async fn observe_process_identity(
         pid,
         birth: fields[3..8].join(" "),
-        executable: fields[8..].join(" "),
+        executable: resolve_executable(pid, fields[8..].join(" ")),
     }))
 }
</file context>

[cubic-dev-ai]

P2: Listing agent sessions now trusts preview hosts for stopped or failed sandboxes even though their URLs are discarded afterward. Because the WebKit exception set is append-only, historical records can grow that set and enqueue unnecessary GTK work; the host should be observed only when a running preview URL is actually returned.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/local-api/src/routes/intercept/sandbox_lifecycle.rs, line 148:

<comment>Listing agent sessions now trusts preview hosts for stopped or failed sandboxes even though their URLs are discarded afterward. Because the WebKit exception set is append-only, historical records can grow that set and enqueue unnecessary GTK work; the host should be observed only when a running preview URL is actually returned.</comment>

<file context>
@@ -108,9 +141,17 @@ fn preview_url(handle: &str) -> Option<String> {
+        // Before the URL escapes: whoever gets it may load it immediately, and
+        // on Linux the host must already be trusted by then.
+        if let Some(observe) = observe {
+            observe(&host);
+        }
+        Some(format!("{scheme}://{host}:{port}/"))
</file context>

[cubic-dev-ai]

P2: A repeat Linux smoke run can validate an old AppImage after Linux bundle configuration or the bundled rclone changes, because this new artifact-reuse path does not track those inputs. Including the Linux overlay and sidecar-fetch inputs in the freshness set would keep the smoke pointed at the artifact produced from current sources.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/scripts/boot-smoke.ts, line 208:

<comment>A repeat Linux smoke run can validate an old AppImage after Linux bundle configuration or the bundled rclone changes, because this new artifact-reuse path does not track those inputs. Including the Linux overlay and sidecar-fetch inputs in the freshness set would keep the smoke pointed at the artifact produced from current sources.</comment>

<file context>
@@ -133,7 +205,8 @@ function newestMtimeUnder(dir: string): number {
 
 async function ensureBuilt(forceRebuild: boolean): Promise<void> {
-  if (!forceRebuild && existsSync(APP_BUNDLE)) {
+  const existing = forceRebuild ? null : findBundleArtifact();
+  if (existing) {
     // Staleness guard: the bundle bakes the frontend + Rust in at build
</file context>

[cubic-dev-ai]

P2: Linux child TLS can fail after a truncated or stale ca-cert.pem: ensure may still build the leaf from the valid key, but this new bundle path appends the corrupted file instead of the CA actually used to sign it. Keeping the persisted CA certificate validated/synchronized with the key before building the bundle would avoid booting with an unusable child trust store.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/src-tauri/src/local_tls.rs, line 327:

<comment>Linux child TLS can fail after a truncated or stale `ca-cert.pem`: `ensure` may still build the leaf from the valid key, but this new bundle path appends the corrupted file instead of the CA actually used to sign it. Keeping the persisted CA certificate validated/synchronized with the key before building the bundle would avoid booting with an unusable child trust store.</comment>

<file context>
@@ -261,13 +279,116 @@ fn is_trusted(ca_cert: &Path) -> bool {
+    app_root: &Path,
+    ca_cert: &Path,
+) -> Result<Option<PathBuf>, TlsError> {
+    let Some(body) = child_ca_bundle_body(system_ca_bundle().as_deref(), &read(ca_cert)?) else {
+        return Ok(None);
+    };
</file context>

[cubic-dev-ai]

P2: A non-empty but non-PEM system file is treated as a valid root store, so the generated replacement bundle can contain no public roots and break the child’s public HTTPS connections. Validating that the candidate contains parseable certificates (or skipping/failing it) would preserve the superset guarantee.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/src-tauri/src/local_tls.rs, line 361:

<comment>A non-empty but non-PEM system file is treated as a valid root store, so the generated replacement bundle can contain no public roots and break the child’s public HTTPS connections. Validating that the candidate contains parseable certificates (or skipping/failing it) would preserve the superset guarantee.</comment>

<file context>
@@ -261,13 +279,116 @@ fn is_trusted(ca_cert: &Path) -> bool {
+
+#[cfg(target_os = "linux")]
+fn read_store(path: &Path) -> Option<String> {
+    let pem = fs::read_to_string(path).ok()?;
+    (!pem.trim().is_empty()).then_some(pem)
+}
</file context>

[cubic-dev-ai]

P3: The Linux smoke launches the extracted AppImage's AppRun, not squashfs-root/usr/bin/deco directly; keeping this comment accurate will avoid misleading failure diagnosis when WebKit/AppRun environment setup is involved.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/native.yml, line 630:

<comment>The Linux smoke launches the extracted AppImage's `AppRun`, not `squashfs-root/usr/bin/deco` directly; keeping this comment accurate will avoid misleading failure diagnosis when WebKit/AppRun environment setup is involved.</comment>

<file context>
@@ -505,6 +623,17 @@ jobs:
+      # only difference is the display. Linux runners are headless, so the
+      # webview needs an X server — `xvfb-run -a` picks a free display
+      # number. The smoke extracts the AppImage it just asserted on (no FUSE
+      # required) and launches the inner binary directly.
+      - name: Boot smoke under Xvfb (DESKTOP_SELFTEST=1, hidden window)
+        if: runner.os == 'Linux'
</file context>

Suggested change

	# required) and launches the inner binary directly.
	# required) and launches the extracted AppImage's AppRun entry point.

[cubic-dev-ai]

P3: Linux documentation builds now have broken ensure_trusted intra-doc links because this platform gate removes the target item. A platform-neutral link or cfg-specific documentation would keep Linux rustdoc warning-free.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/src-tauri/src/local_tls.rs, line 60:

<comment>Linux documentation builds now have broken `ensure_trusted` intra-doc links because this platform gate removes the target item. A platform-neutral link or cfg-specific documentation would keep Linux rustdoc warning-free.</comment>

<file context>
@@ -37,13 +37,27 @@
 
 use std::fs;
 use std::path::{Path, PathBuf};
+#[cfg(target_os = "macos")]
 use std::process::Command;
 
</file context>

[cubic-dev-ai]

P3: On Linux the added xdg-open path still uses .spawn().map(|_| ()), so a non-zero xdg-open exit (no browser, no DISPLAY) is reported as success. The new doc comment's soft-fail promise only holds when the binary itself is missing; in the common headless/bare-session case the caller logs "system browser launched" and the user hangs until the 5-min loopback timeout. Consider waiting on and checking xdg-open's exit status so the soft-fail (log URL) path in perform_interactive_login actually triggers, or capture stderr for the log.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/upstream/src/login.rs, line 317:

<comment>On Linux the added xdg-open path still uses `.spawn().map(|_| ())`, so a non-zero xdg-open exit (no browser, no DISPLAY) is reported as success. The new doc comment's soft-fail promise only holds when the binary itself is missing; in the common headless/bare-session case the caller logs "system browser launched" and the user hangs until the 5-min loopback timeout. Consider waiting on and checking xdg-open's exit status so the soft-fail (log URL) path in perform_interactive_login actually triggers, or capture stderr for the log.</comment>

<file context>
@@ -300,12 +300,21 @@ pub(crate) async fn mint_session_from_access_token(
+    #[cfg(not(target_os = "macos"))]
+    const OPENER: &str = "xdg-open";
+
+    std::process::Command::new(OPENER)
         .arg(url)
         .stdin(std::process::Stdio::null())
</file context>

[cubic-dev-ai]

3 issues found across 34 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name=".github/workflows/native.yml">

<violation number="1" location=".github/workflows/native.yml:188">
P3: The job-level `timeout-minutes: 60` is the real ceiling for the Linux test leg, but the per-step budgets are set as if each is independently achievable — their worst-case sum (40 + 10 + 10 + 4×12 + 12 + 10) is ~110 min. On a cold cache where the `--no-run` build uses a large share of the 60-minute budget, the later per-crate/per-module steps get clipped by the job cap, which is precisely the partial-coverage, mid-run-stop outcome the diff is trying to eliminate. Consider raising the job timeout to match the sum of its bounded steps, or moving the `--no-run` build into its own job, so the per-step timeouts (not the job cap) are what actually bound each step.</violation>

<violation number="2" location=".github/workflows/native.yml:387">
P3: The `local-api tests — whole crate` step re-runs every test that the four preceding `--test-threads=1` filter steps (process_group, process_util, setup, sandbox, routes) already ran, so the local-api suite executes ~twice on the Linux test leg. That leg is exactly the one this PR is fighting to keep under its runtime/disk limits, and the extra pass also re-exposes the process-group tests in parallel (only bounded by `setsid`) after they were deliberately isolated single-threaded. If the whole-crate step is meant to pick up the non-filtered modules, consider running only the remaining tests (or documenting why the duplicate full run is required) rather than repeating the whole suite.</violation>

<violation number="3" location=".github/workflows/native.yml:875">
P1: A failure in the `changes` gate can produce a green required check: the matrix job becomes `skipped`, and this branch treats that as success. The aggregators should accept `skipped` only when `needs.changes.result` is successful, applying the same guard to all three required-check jobs.</violation>
</file>

<sub>Tip: cubic can generate docs of your entire codebase and keep them up to date. Try it here.

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: A failure in the changes gate can produce a green required check: the matrix job becomes skipped, and this branch treats that as success. The aggregators should accept skipped only when needs.changes.result is successful, applying the same guard to all three required-check jobs.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/native.yml, line 875:

<comment>A failure in the `changes` gate can produce a green required check: the matrix job becomes `skipped`, and this branch treats that as success. The aggregators should accept `skipped` only when `needs.changes.result` is successful, applying the same guard to all three required-check jobs.</comment>

<file context>
@@ -561,3 +858,54 @@ jobs:
+      - name: Verify rust-checks legs
+        run: |
+          case "${{ needs.rust-checks-os.result }}" in
+            success|skipped) echo "rust-checks: ${{ needs.rust-checks-os.result }}"; exit 0 ;;
+            *) echo "rust-checks: ${{ needs.rust-checks-os.result }}"; exit 1 ;;
+          esac
</file context>

[cubic-dev-ai]

P3: The job-level timeout-minutes: 60 is the real ceiling for the Linux test leg, but the per-step budgets are set as if each is independently achievable — their worst-case sum (40 + 10 + 10 + 4×12 + 12 + 10) is ~110 min. On a cold cache where the --no-run build uses a large share of the 60-minute budget, the later per-crate/per-module steps get clipped by the job cap, which is precisely the partial-coverage, mid-run-stop outcome the diff is trying to eliminate. Consider raising the job timeout to match the sum of its bounded steps, or moving the --no-run build into its own job, so the per-step timeouts (not the job cap) are what actually bound each step.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/native.yml, line 188:

<comment>The job-level `timeout-minutes: 60` is the real ceiling for the Linux test leg, but the per-step budgets are set as if each is independently achievable — their worst-case sum (40 + 10 + 10 + 4×12 + 12 + 10) is ~110 min. On a cold cache where the `--no-run` build uses a large share of the 60-minute budget, the later per-crate/per-module steps get clipped by the job cap, which is precisely the partial-coverage, mid-run-stop outcome the diff is trying to eliminate. Consider raising the job timeout to match the sum of its bounded steps, or moving the `--no-run` build into its own job, so the per-step timeouts (not the job cap) are what actually bound each step.</comment>

<file context>
@@ -140,19 +140,52 @@ jobs:
+    # glib, soup) from source, once for clippy's dev profile and again for
+    # test's — where macOS links system frameworks and finishes in ~3 min.
+    # A cold cache ran 25-35 min and was killed mid-`cargo test` at 30.
+    timeout-minutes: 60
     steps:
       - name: Checkout repository
</file context>

[cubic-dev-ai]

P3: The local-api tests — whole crate step re-runs every test that the four preceding --test-threads=1 filter steps (process_group, process_util, setup, sandbox, routes) already ran, so the local-api suite executes ~twice on the Linux test leg. That leg is exactly the one this PR is fighting to keep under its runtime/disk limits, and the extra pass also re-exposes the process-group tests in parallel (only bounded by setsid) after they were deliberately isolated single-threaded. If the whole-crate step is meant to pick up the non-filtered modules, consider running only the remaining tests (or documenting why the duplicate full run is required) rather than repeating the whole suite.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/native.yml, line 387:

<comment>The `local-api tests — whole crate` step re-runs every test that the four preceding `--test-threads=1` filter steps (process_group, process_util, setup, sandbox, routes) already ran, so the local-api suite executes ~twice on the Linux test leg. That leg is exactly the one this PR is fighting to keep under its runtime/disk limits, and the extra pass also re-exposes the process-group tests in parallel (only bounded by `setsid`) after they were deliberately isolated single-threaded. If the whole-crate step is meant to pick up the non-filtered modules, consider running only the remaining tests (or documenting why the duplicate full run is required) rather than repeating the whole suite.</comment>

<file context>
@@ -196,13 +272,129 @@ jobs:
+        env:
+          CARGO_BUILD_JOBS: "2"
+        run: |
+          setsid --wait cargo test -p local-api
+
+
</file context>

[cubic-dev-ai]

2 issues found across 35 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name=".github/workflows/native.yml">

<violation number="1" location=".github/workflows/native.yml:387">
P2: The 'local-api tests — whole crate' step re-runs the full local-api suite right after process_group/process_util/setup/sandbox/routes were each run individually in their own steps. That re-executes all five already-covered modules, doubling the most expensive crate's test time on exactly the leg the per-module split was meant to isolate. Since this whole job shares a single 60-minute budget, the redundant pass wastes real time and raises the chance the leg is cut off mid-suite. Consider running only the modules the split steps don't already cover via `--skip process_group:: --skip process_util:: --skip setup:: --skip sandbox:: --skip routes::`, or drop the blanket run if the five split steps plus harness/upstream/deco are the intended coverage.</violation>

<violation number="2" location=".github/workflows/native.yml:875">
P1: A failure in the `changes` gate is currently converted into a green required check: because the aggregator runs with `always()` and accepts `rust-checks-os.result == skipped`, a failed gate skips the matrix and still reports success. The aggregators would need to require `needs.changes.result == 'success'` before treating a skipped matrix as an intentional irrelevant-paths pass; apply the same guard to `contract-suite` and `tauri-build`.</violation>
</file>

<sub>Tip: cubic can generate docs of your entire codebase and keep them up to date. Try it here.

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: A failure in the changes gate is currently converted into a green required check: because the aggregator runs with always() and accepts rust-checks-os.result == skipped, a failed gate skips the matrix and still reports success. The aggregators would need to require needs.changes.result == 'success' before treating a skipped matrix as an intentional irrelevant-paths pass; apply the same guard to contract-suite and tauri-build.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/native.yml, line 875:

<comment>A failure in the `changes` gate is currently converted into a green required check: because the aggregator runs with `always()` and accepts `rust-checks-os.result == skipped`, a failed gate skips the matrix and still reports success. The aggregators would need to require `needs.changes.result == 'success'` before treating a skipped matrix as an intentional irrelevant-paths pass; apply the same guard to `contract-suite` and `tauri-build`.</comment>

<file context>
@@ -561,3 +858,54 @@ jobs:
+      - name: Verify rust-checks legs
+        run: |
+          case "${{ needs.rust-checks-os.result }}" in
+            success|skipped) echo "rust-checks: ${{ needs.rust-checks-os.result }}"; exit 0 ;;
+            *) echo "rust-checks: ${{ needs.rust-checks-os.result }}"; exit 1 ;;
+          esac
</file context>

[cubic-dev-ai]

P2: The 'local-api tests — whole crate' step re-runs the full local-api suite right after process_group/process_util/setup/sandbox/routes were each run individually in their own steps. That re-executes all five already-covered modules, doubling the most expensive crate's test time on exactly the leg the per-module split was meant to isolate. Since this whole job shares a single 60-minute budget, the redundant pass wastes real time and raises the chance the leg is cut off mid-suite. Consider running only the modules the split steps don't already cover via --skip process_group:: --skip process_util:: --skip setup:: --skip sandbox:: --skip routes::, or drop the blanket run if the five split steps plus harness/upstream/deco are the intended coverage.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/native.yml, line 387:

<comment>The 'local-api tests — whole crate' step re-runs the full local-api suite right after process_group/process_util/setup/sandbox/routes were each run individually in their own steps. That re-executes all five already-covered modules, doubling the most expensive crate's test time on exactly the leg the per-module split was meant to isolate. Since this whole job shares a single 60-minute budget, the redundant pass wastes real time and raises the chance the leg is cut off mid-suite. Consider running only the modules the split steps don't already cover via `--skip process_group:: --skip process_util:: --skip setup:: --skip sandbox:: --skip routes::`, or drop the blanket run if the five split steps plus harness/upstream/deco are the intended coverage.</comment>

<file context>
@@ -196,13 +272,129 @@ jobs:
+        env:
+          CARGO_BUILD_JOBS: "2"
+        run: |
+          setsid --wait cargo test -p local-api
+
+
</file context>

[cubic-dev-ai]

3 issues found across 35 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="apps/native/crates/local-api/src/process_group.rs">

<violation number="1" location="apps/native/crates/local-api/src/process_group.rs:715">
P2: When the `ps` probe is unavailable or returns a non-self PGID, this fallback kills only the shell PID, but the `sh -c "sleep 30"` fixture may retain `sleep` as a child. Since this test's unanchored `wait` checks only the direct child, it can pass while leaking a background process; a single-process fixture or descendant-aware fallback would make the cleanup assertion reliable.</violation>
</file>

<file name=".github/workflows/native.yml">

<violation number="1" location=".github/workflows/native.yml:392">
P2: Linux CI can still intermittently fail or strand process-group children because the final full-crate run reruns the process-spawning tests in parallel. Keeping this run single-threaded would preserve the Linux-specific isolation used by the filtered runs.</violation>

<violation number="2" location=".github/workflows/native.yml:880">
P1: A failure in the `changes` gate can currently make this required check pass: `always()` still runs the aggregator, and the `skipped` downstream result is accepted even when `changes` itself failed. The `contract-suite` and `tauri-build` aggregators repeat the same pattern, so their cases should require `needs.changes.result == 'success'` before accepting a skipped matrix.</violation>
</file>

<sub>Tip: cubic can generate docs of your entire codebase and keep them up to date. Try it here.

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: A failure in the changes gate can currently make this required check pass: always() still runs the aggregator, and the skipped downstream result is accepted even when changes itself failed. The contract-suite and tauri-build aggregators repeat the same pattern, so their cases should require needs.changes.result == 'success' before accepting a skipped matrix.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/native.yml, line 880:

<comment>A failure in the `changes` gate can currently make this required check pass: `always()` still runs the aggregator, and the `skipped` downstream result is accepted even when `changes` itself failed. The `contract-suite` and `tauri-build` aggregators repeat the same pattern, so their cases should require `needs.changes.result == 'success'` before accepting a skipped matrix.</comment>

<file context>
@@ -561,3 +863,54 @@ jobs:
+      - name: Verify rust-checks legs
+        run: |
+          case "${{ needs.rust-checks-os.result }}" in
+            success|skipped) echo "rust-checks: ${{ needs.rust-checks-os.result }}"; exit 0 ;;
+            *) echo "rust-checks: ${{ needs.rust-checks-os.result }}"; exit 1 ;;
+          esac
</file context>

[cubic-dev-ai]

P2: When the ps probe is unavailable or returns a non-self PGID, this fallback kills only the shell PID, but the sh -c "sleep 30" fixture may retain sleep as a child. Since this test's unanchored wait checks only the direct child, it can pass while leaking a background process; a single-process fixture or descendant-aware fallback would make the cleanup assertion reliable.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/local-api/src/process_group.rs, line 715:

<comment>When the `ps` probe is unavailable or returns a non-self PGID, this fallback kills only the shell PID, but the `sh -c "sleep 30"` fixture may retain `sleep` as a child. Since this test's unanchored `wait` checks only the direct child, it can pass while leaking a background process; a single-process fixture or descendant-aware fallback would make the cleanup assertion reliable.</comment>

<file context>
@@ -697,8 +697,25 @@ mod tests {
+        let target = if leads_own_group {
+            format!("-{pid}")
+        } else {
+            pid.to_string()
+        };
         let _ = std::process::Command::new("kill")
</file context>

[cubic-dev-ai]

P2: Linux CI can still intermittently fail or strand process-group children because the final full-crate run reruns the process-spawning tests in parallel. Keeping this run single-threaded would preserve the Linux-specific isolation used by the filtered runs.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/native.yml, line 392:

<comment>Linux CI can still intermittently fail or strand process-group children because the final full-crate run reruns the process-spawning tests in parallel. Keeping this run single-threaded would preserve the Linux-specific isolation used by the filtered runs.</comment>

<file context>
@@ -196,13 +272,134 @@ jobs:
+        env:
+          CARGO_BUILD_JOBS: "2"
+        run: |
+          setsid --wait cargo test -p local-api
+
+
</file context>

Suggested change

	setsid --wait cargo test -p local-api
	setsid --wait cargo test -p local-api -- --test-threads=1

[cubic-dev-ai]

2 issues found across 35 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="apps/native/crates/local-api/src/process_group.rs">

<violation number="1" location="apps/native/crates/local-api/src/process_group.rs:684">
P2: Linux CI now skips `cleanup_warning_deadline_does_not_release_an_unreaped_owner`, so the target platform no longer exercises the invariant that an expired cleanup warning retains an unreaped owner. The runner-kill symptom is documented, but this leaves the Linux process-group behavior unverified; an explicit opt-in job or Linux-safe replacement would preserve coverage without making the default suite silently green.</violation>
</file>

<file name=".github/workflows/native.yml">

<violation number="1" location=".github/workflows/native.yml:790">
P1: A failure in the `changes` gate can currently make all three required checks pass without running any macOS/Linux leg, because a failed dependency leaves each matrix job `skipped` and this branch treats that as success. The aggregators should require `needs.changes.result == 'success'` before accepting a skipped child; reserve the skipped case for a successful path-filter decision.</violation>
</file>

<sub>Tip: cubic can generate docs of your entire codebase and keep them up to date. Try it here.

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: A failure in the changes gate can currently make all three required checks pass without running any macOS/Linux leg, because a failed dependency leaves each matrix job skipped and this branch treats that as success. The aggregators should require needs.changes.result == 'success' before accepting a skipped child; reserve the skipped case for a successful path-filter decision.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/native.yml, line 790:

<comment>A failure in the `changes` gate can currently make all three required checks pass without running any macOS/Linux leg, because a failed dependency leaves each matrix job `skipped` and this branch treats that as success. The aggregators should require `needs.changes.result == 'success'` before accepting a skipped child; reserve the skipped case for a successful path-filter decision.</comment>

<file context>
@@ -561,3 +774,54 @@ jobs:
+    steps:
+      - name: Verify rust-checks legs
+        run: |
+          case "${{ needs.rust-checks-os.result }}" in
+            success|skipped) echo "rust-checks: ${{ needs.rust-checks-os.result }}"; exit 0 ;;
+            *) echo "rust-checks: ${{ needs.rust-checks-os.result }}"; exit 1 ;;
</file context>

[cubic-dev-ai]

P2: Linux CI now skips cleanup_warning_deadline_does_not_release_an_unreaped_owner, so the target platform no longer exercises the invariant that an expired cleanup warning retains an unreaped owner. The runner-kill symptom is documented, but this leaves the Linux process-group behavior unverified; an explicit opt-in job or Linux-safe replacement would preserve coverage without making the default suite silently green.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/local-api/src/process_group.rs, line 684:

<comment>Linux CI now skips `cleanup_warning_deadline_does_not_release_an_unreaped_owner`, so the target platform no longer exercises the invariant that an expired cleanup warning retains an unreaped owner. The runner-kill symptom is documented, but this leaves the Linux process-group behavior unverified; an explicit opt-in job or Linux-safe replacement would preserve coverage without making the default suite silently green.</comment>

<file context>
@@ -666,6 +666,22 @@ mod tests {
+    /// an owner that was never reaped — is not Linux-specific, and macOS still
+    /// runs it every CI run. Un-ignore this the moment someone can reproduce
+    /// it locally on Linux; do not delete it.
+    #[cfg_attr(target_os = "linux", ignore)]
     #[cfg(unix)]
     #[tokio::test]
</file context>

[cubic-dev-ai]

4 issues found across 35 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name=".github/workflows/native.yml">

<violation number="1" location=".github/workflows/native.yml:790">
P2: A failure in the `changes` gate can make all required aggregators pass while their test/build matrices are skipped, allowing a PR through without validation. The aggregator condition should include `needs.changes.result` and only accept `success`/`skipped` for the matrix when the changes job itself succeeded; the same guard is needed in the contract-suite and tauri-build aggregators.</violation>
</file>

<file name="apps/native/crates/local-api/src/process_group.rs">

<violation number="1" location="apps/native/crates/local-api/src/process_group.rs:712">
P3: When `ps` cannot prove the process group, this test kills only the shell and leaks its `sleep 30` descendant. A failed/missing `ps` therefore leaves orphaned processes across test runs; using a fixture that `exec`s the long-lived process or explicitly cleaning the descendant would keep the fallback safe without leaking.</violation>
</file>

<file name="apps/native/crates/harness/src/watchdog.rs">

<violation number="1" location="apps/native/crates/harness/src/watchdog.rs:55">
P2: The watchdog writes its PID list through a predictable temporary path, allowing another local process to redirect or interfere with enumeration and potentially overwrite an unrelated file. Creating the per-anchor file with `mktemp` (and retaining the fail-closed behavior if creation fails) would avoid this temp-file race.</violation>

<violation number="2" location="apps/native/crates/harness/src/watchdog.rs:61">
P1: An output-file open failure can be misclassified as an empty process group, so the anchor may release the inherited lifetime lock while workloads remain alive. Opening the file descriptor separately and returning the enumeration-error status when that open fails would preserve the watchdog's fail-closed contract.</violation>
</file>

<sub>Tip: cubic can generate docs of your entire codebase and keep them up to date. Try it here.

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: An output-file open failure can be misclassified as an empty process group, so the anchor may release the inherited lifetime lock while workloads remain alive. Opening the file descriptor separately and returning the enumeration-error status when that open fails would preserve the watchdog's fail-closed contract.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/harness/src/watchdog.rs, line 61:

<comment>An output-file open failure can be misclassified as an empty process group, so the anchor may release the inherited lifetime lock while workloads remain alive. Opening the file descriptor separately and returning the enumeration-error status when that open fails would preserve the watchdog's fail-closed contract.</comment>

<file context>
@@ -24,55 +24,75 @@
-while [ "$term_round" -lt 20 ]; do
-  members="$(pgrep -g "$$" . 2>/dev/null)"
+signal_round() {
+  pgrep -g "$$" . > "$members_file" 2>/dev/null
   status=$?
   if [ "$status" -eq 1 ]; then
</file context>

Suggested change

	pgrep -g "$$" . > "$members_file" 2>/dev/null
	status=$?
	exec 3>"$members_file" || return 3
	pgrep -g "$$" . >&3 2>/dev/null
	status=$?
	exec 3>&-

[cubic-dev-ai]

P2: A failure in the changes gate can make all required aggregators pass while their test/build matrices are skipped, allowing a PR through without validation. The aggregator condition should include needs.changes.result and only accept success/skipped for the matrix when the changes job itself succeeded; the same guard is needed in the contract-suite and tauri-build aggregators.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/native.yml, line 790:

<comment>A failure in the `changes` gate can make all required aggregators pass while their test/build matrices are skipped, allowing a PR through without validation. The aggregator condition should include `needs.changes.result` and only accept `success`/`skipped` for the matrix when the changes job itself succeeded; the same guard is needed in the contract-suite and tauri-build aggregators.</comment>

<file context>
@@ -561,3 +774,54 @@ jobs:
+    steps:
+      - name: Verify rust-checks legs
+        run: |
+          case "${{ needs.rust-checks-os.result }}" in
+            success|skipped) echo "rust-checks: ${{ needs.rust-checks-os.result }}"; exit 0 ;;
+            *) echo "rust-checks: ${{ needs.rust-checks-os.result }}"; exit 1 ;;
</file context>

[cubic-dev-ai]

P2: The watchdog writes its PID list through a predictable temporary path, allowing another local process to redirect or interfere with enumeration and potentially overwrite an unrelated file. Creating the per-anchor file with mktemp (and retaining the fail-closed behavior if creation fails) would avoid this temp-file race.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/harness/src/watchdog.rs, line 55:

<comment>The watchdog writes its PID list through a predictable temporary path, allowing another local process to redirect or interfere with enumeration and potentially overwrite an unrelated file. Creating the per-anchor file with `mktemp` (and retaining the fail-closed behavior if creation fails) would avoid this temp-file race.</comment>

<file context>
@@ -24,55 +24,75 @@
+# BSD `pgrep` omits its ancestors, which hides the subshell and is why macOS
+# never showed it. A file keeps the enumeration free of any process this
+# script creates to read it.
+members_file="${TMPDIR:-/tmp}/decocms-anchor-$$"
+trap 'rm -f "$members_file"' EXIT
+
</file context>

Suggested change

	members_file="${TMPDIR:-/tmp}/decocms-anchor-$$"
	members_file="$(mktemp "${TMPDIR:-/tmp}/decocms-anchor.XXXXXX")" || while :; do sleep 60; done

[cubic-dev-ai]

P3: When ps cannot prove the process group, this test kills only the shell and leaks its sleep 30 descendant. A failed/missing ps therefore leaves orphaned processes across test runs; using a fixture that execs the long-lived process or explicitly cleaning the descendant would keep the fallback safe without leaking.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/local-api/src/process_group.rs, line 712:

<comment>When `ps` cannot prove the process group, this test kills only the shell and leaks its `sleep 30` descendant. A failed/missing `ps` therefore leaves orphaned processes across test runs; using a fixture that `exec`s the long-lived process or explicitly cleaning the descendant would keep the fallback safe without leaking.</comment>

<file context>
@@ -697,8 +697,25 @@ mod tests {
+            .ok()
+            .and_then(|out| String::from_utf8(out.stdout).ok())
+            .is_some_and(|out| out.trim().parse::<u32>() == Ok(pid));
+        let target = if leads_own_group {
+            format!("-{pid}")
+        } else {
</file context>

[github-actions]

A comment that takes a paragraph to justify a workaround is a signal the code is wrong, not the comment — fix the code, don't explain it away (CLAUDE.md).

[cubic-dev-ai]

2 issues found across 36 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name=".github/workflows/native.yml">

<violation number="1" location=".github/workflows/native.yml:790">
P1: A failure or cancellation of the `changes` gate can be reported as a passing required check: the downstream matrix is skipped, and this `case` treats `skipped` as success. The aggregators should first require `needs.changes.result == 'success'`, then accept `skipped` only for a successfully evaluated irrelevant-path gate.</violation>
</file>

<file name="apps/native/crates/harness/src/watchdog.rs">

<violation number="1" location="apps/native/crates/harness/src/watchdog.rs:55">
P2: The watchdog can truncate an arbitrary file in the shared temp directory because this predictable `$$` path is opened with `>` rather than exclusive creation. Creating the list with `mktemp` (and parking on creation failure to preserve fail-closed cleanup) would prevent symlink/path-collision writes.</violation>
</file>

<sub>Tip: cubic can generate docs of your entire codebase and keep them up to date. Try it here.

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: A failure or cancellation of the changes gate can be reported as a passing required check: the downstream matrix is skipped, and this case treats skipped as success. The aggregators should first require needs.changes.result == 'success', then accept skipped only for a successfully evaluated irrelevant-path gate.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/native.yml, line 790:

<comment>A failure or cancellation of the `changes` gate can be reported as a passing required check: the downstream matrix is skipped, and this `case` treats `skipped` as success. The aggregators should first require `needs.changes.result == 'success'`, then accept `skipped` only for a successfully evaluated irrelevant-path gate.</comment>

<file context>
@@ -561,3 +774,54 @@ jobs:
+    steps:
+      - name: Verify rust-checks legs
+        run: |
+          case "${{ needs.rust-checks-os.result }}" in
+            success|skipped) echo "rust-checks: ${{ needs.rust-checks-os.result }}"; exit 0 ;;
+            *) echo "rust-checks: ${{ needs.rust-checks-os.result }}"; exit 1 ;;
</file context>

[cubic-dev-ai]

P2: The watchdog can truncate an arbitrary file in the shared temp directory because this predictable $$ path is opened with > rather than exclusive creation. Creating the list with mktemp (and parking on creation failure to preserve fail-closed cleanup) would prevent symlink/path-collision writes.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/harness/src/watchdog.rs, line 55:

<comment>The watchdog can truncate an arbitrary file in the shared temp directory because this predictable `$$` path is opened with `>` rather than exclusive creation. Creating the list with `mktemp` (and parking on creation failure to preserve fail-closed cleanup) would prevent symlink/path-collision writes.</comment>

<file context>
@@ -24,55 +24,75 @@
+# BSD `pgrep` omits its ancestors, which hides the subshell and is why macOS
+# never showed it. A file keeps the enumeration free of any process this
+# script creates to read it.
+members_file="${TMPDIR:-/tmp}/decocms-anchor-$$"
+trap 'rm -f "$members_file"' EXIT
+
</file context>

Suggested change

	members_file="${TMPDIR:-/tmp}/decocms-anchor-$$"
	members_file="$(mktemp "${TMPDIR:-/tmp}/decocms-anchor-XXXXXX")" || while :; do sleep 60; done

[cubic-dev-ai]

4 issues found across 37 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="apps/native/crates/harness/src/watchdog.rs">

<violation number="1" location="apps/native/crates/harness/src/watchdog.rs:55">
P2: Crash recovery can become permanently wedged for an invalid `TMPDIR`, while a pre-created PID-based symlink can redirect each enumeration write to an attacker-selected file. Creating the path with `mktemp` using a `/tmp` fallback would avoid both the symlink/collision risk and dependence on a writable inherited directory.</violation>
</file>

<file name=".github/workflows/native.yml">

<violation number="1" location=".github/workflows/native.yml:791">
P1: A failed or cancelled `changes` gate is treated the same as an intentionally irrelevant PR: the skipped matrix result makes this required check pass without running any legs. The aggregators would be safer if they first required `needs.changes.result == 'success'`, while still allowing a skipped matrix only after a successful changes gate; the same guard is needed in `contract-suite` and `tauri-build`.</violation>
</file>

<file name="apps/native/crates/local-api/src/process_group.rs">

<violation number="1" location="apps/native/crates/local-api/src/process_group.rs:689">
P2: Linux CI now skips this process-group cleanup test entirely, so the Linux build can pass while the ownership/reap path regresses. Isolating the flaky fixture or moving the OOM investigation into a separate subprocess would preserve this coverage instead of masking it with a platform-wide ignore.</violation>

<violation number="2" location="apps/native/crates/local-api/src/process_group.rs:733">
P2: When `ps` is unavailable or its output is not parseable, this fallback kills only the shell PID even though the `sleep 30` fixture can have a separate descendant, allowing cleanup to finish with an orphaned process. A process-tree-safe fallback or explicit descendant cleanup would avoid leaking fixtures when the probe fails.</violation>
</file>

<sub>Tip: cubic can generate docs of your entire codebase and keep them up to date. Try it here.

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: A failed or cancelled changes gate is treated the same as an intentionally irrelevant PR: the skipped matrix result makes this required check pass without running any legs. The aggregators would be safer if they first required needs.changes.result == 'success', while still allowing a skipped matrix only after a successful changes gate; the same guard is needed in contract-suite and tauri-build.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/native.yml, line 791:

<comment>A failed or cancelled `changes` gate is treated the same as an intentionally irrelevant PR: the skipped matrix result makes this required check pass without running any legs. The aggregators would be safer if they first required `needs.changes.result == 'success'`, while still allowing a skipped matrix only after a successful changes gate; the same guard is needed in `contract-suite` and `tauri-build`.</comment>

<file context>
@@ -561,3 +774,54 @@ jobs:
+      - name: Verify rust-checks legs
+        run: |
+          case "${{ needs.rust-checks-os.result }}" in
+            success|skipped) echo "rust-checks: ${{ needs.rust-checks-os.result }}"; exit 0 ;;
+            *) echo "rust-checks: ${{ needs.rust-checks-os.result }}"; exit 1 ;;
+          esac
</file context>

[cubic-dev-ai]

P2: Crash recovery can become permanently wedged for an invalid TMPDIR, while a pre-created PID-based symlink can redirect each enumeration write to an attacker-selected file. Creating the path with mktemp using a /tmp fallback would avoid both the symlink/collision risk and dependence on a writable inherited directory.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/harness/src/watchdog.rs, line 55:

<comment>Crash recovery can become permanently wedged for an invalid `TMPDIR`, while a pre-created PID-based symlink can redirect each enumeration write to an attacker-selected file. Creating the path with `mktemp` using a `/tmp` fallback would avoid both the symlink/collision risk and dependence on a writable inherited directory.</comment>

<file context>
@@ -24,55 +24,75 @@
+# BSD `pgrep` omits its ancestors, which hides the subshell and is why macOS
+# never showed it. A file keeps the enumeration free of any process this
+# script creates to read it.
+members_file="${TMPDIR:-/tmp}/decocms-anchor-$$"
+trap 'rm -f "$members_file"' EXIT
+
</file context>

Suggested change

	members_file="${TMPDIR:-/tmp}/decocms-anchor-$$"
	members_file="$(mktemp "${TMPDIR:-/tmp}/decocms-anchor-XXXXXX" 2>/dev/null || mktemp /tmp/decocms-anchor-XXXXXX)" || while :; do sleep 60; done

[cubic-dev-ai]

P2: When ps is unavailable or its output is not parseable, this fallback kills only the shell PID even though the sleep 30 fixture can have a separate descendant, allowing cleanup to finish with an orphaned process. A process-tree-safe fallback or explicit descendant cleanup would avoid leaking fixtures when the probe fails.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/local-api/src/process_group.rs, line 733:

<comment>When `ps` is unavailable or its output is not parseable, this fallback kills only the shell PID even though the `sleep 30` fixture can have a separate descendant, allowing cleanup to finish with an orphaned process. A process-tree-safe fallback or explicit descendant cleanup would avoid leaking fixtures when the probe fails.</comment>

<file context>
@@ -697,8 +718,25 @@ mod tests {
+            .ok()
+            .and_then(|out| String::from_utf8(out.stdout).ok())
+            .is_some_and(|out| out.trim().parse::<u32>() == Ok(pid));
+        let target = if leads_own_group {
+            format!("-{pid}")
+        } else {
</file context>

[cubic-dev-ai]

P2: Linux CI now skips this process-group cleanup test entirely, so the Linux build can pass while the ownership/reap path regresses. Isolating the flaky fixture or moving the OOM investigation into a separate subprocess would preserve this coverage instead of masking it with a platform-wide ignore.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/local-api/src/process_group.rs, line 689:

<comment>Linux CI now skips this process-group cleanup test entirely, so the Linux build can pass while the ownership/reap path regresses. Isolating the flaky fixture or moving the OOM investigation into a separate subprocess would preserve this coverage instead of masking it with a platform-wide ignore.</comment>

<file context>
@@ -666,6 +666,27 @@ mod tests {
+    /// `routes::git::tests::slow_git_group_is_term_kill_reaped_before_owner_finalizes`
+    /// is ignored for the same reason. Both drive the TERM-then-KILL group
+    /// reap, so treat them as one investigation rather than two.
+    #[cfg_attr(target_os = "linux", ignore)]
     #[cfg(unix)]
     #[tokio::test]
</file context>

[cubic-dev-ai]

5 issues found across 36 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="apps/native/crates/local-api/src/process_group.rs">

<violation number="1" location="apps/native/crates/local-api/src/process_group.rs:700">
P3: The comment describes the negative-PID failure mode incorrectly: `kill -KILL -<pid>` targets only process group `<pid>`, and a missing group fails rather than signaling the test binary. Rewording this explanation would prevent future debugging and safety decisions from relying on impossible Linux behavior.</violation>

<violation number="2" location="apps/native/crates/local-api/src/process_group.rs:712">
P3: When `ps` is unavailable or unparsable, this fallback kills only the shell leader, so the `sh -c "sleep 30"` fixture can leave its separate `sleep` child running for 30 seconds even though the cleanup task completes. A direct `sleep` fixture or explicit descendant cleanup would keep the test from leaking processes on Unix environments without a usable `ps`.</violation>
</file>

<file name=".github/workflows/native.yml">

<violation number="1" location=".github/workflows/native.yml:305">
P2: The Linux test leg can time out before completing on the cold-cache path this workflow explicitly describes: `cargo test (Linux)` is capped at 25 minutes while the documented cold build takes up to 35 minutes. A step timeout comfortably above the observed 35-minute build (or no step-level timeout) would leave the existing 60-minute job cap as the safety bound.</violation>

<violation number="2" location=".github/workflows/native.yml:802">
P2: A failure in the `changes` gate can make the required aggregator green without running its matrix legs: the dependent matrix is skipped, and `success|skipped` is accepted without checking `needs.changes.result`. The aggregators would preserve the intended irrelevant-path behavior while failing closed if they explicitly rejected a non-success `changes` result.</violation>
</file>

<file name="apps/native/crates/harness/src/watchdog.rs">

<violation number="1" location="apps/native/crates/harness/src/watchdog.rs:55">
P2: The new members_file is written to a fixed, guessable path (`${TMPDIR:-/tmp}/decocms-anchor-$$`) with plain `>` truncation. On Linux this usually resolves to world-writable `/tmp`, so a local user who can guess the PID ahead of boot could plant a symlink at that path and cause the watchdog to truncate/overwrite an arbitrary file the app user can write, and the pgrep PID output is briefly world-readable (0644). Prefer creating the file with `mktemp` (gives 0600 perms and a non-guessable name) instead of a predictable `decocms-anchor-<pid>` path. Note this is safe w.r.t. the subshell concern: mktemp runs once at script startup before the enumeration loops, and its transient subshell exits before any `pgrep` pass.</violation>
</file>

<sub>Tip: cubic can generate docs of your entire codebase and keep them up to date. Try it here.

Re-trigger cubic</sub>

[cubic-dev-ai]

P2: A failure in the changes gate can make the required aggregator green without running its matrix legs: the dependent matrix is skipped, and success|skipped is accepted without checking needs.changes.result. The aggregators would preserve the intended irrelevant-path behavior while failing closed if they explicitly rejected a non-success changes result.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/native.yml, line 802:

<comment>A failure in the `changes` gate can make the required aggregator green without running its matrix legs: the dependent matrix is skipped, and `success|skipped` is accepted without checking `needs.changes.result`. The aggregators would preserve the intended irrelevant-path behavior while failing closed if they explicitly rejected a non-success `changes` result.</comment>

<file context>
@@ -561,3 +785,54 @@ jobs:
+      - name: Verify rust-checks legs
+        run: |
+          case "${{ needs.rust-checks-os.result }}" in
+            success|skipped) echo "rust-checks: ${{ needs.rust-checks-os.result }}"; exit 0 ;;
+            *) echo "rust-checks: ${{ needs.rust-checks-os.result }}"; exit 1 ;;
+          esac
</file context>

[cubic-dev-ai]

P2: The Linux test leg can time out before completing on the cold-cache path this workflow explicitly describes: cargo test (Linux) is capped at 25 minutes while the documented cold build takes up to 35 minutes. A step timeout comfortably above the observed 35-minute build (or no step-level timeout) would leave the existing 60-minute job cap as the safety bound.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/native.yml, line 305:

<comment>The Linux test leg can time out before completing on the cold-cache path this workflow explicitly describes: `cargo test (Linux)` is capped at 25 minutes while the documented cold build takes up to 35 minutes. A step timeout comfortably above the observed 35-minute build (or no step-level timeout) would leave the existing 60-minute job cap as the safety bound.</comment>

<file context>
@@ -196,13 +272,56 @@ jobs:
+      - name: cargo test (Linux)
+        if: runner.os == 'Linux' && matrix.task != 'lint'
+        working-directory: apps/native
+        timeout-minutes: 25
+        env:
+          CARGO_BUILD_JOBS: "2"
</file context>

Suggested change

	timeout-minutes: 25
	timeout-minutes: 45

[cubic-dev-ai]

P2: The new members_file is written to a fixed, guessable path (${TMPDIR:-/tmp}/decocms-anchor-$$) with plain > truncation. On Linux this usually resolves to world-writable /tmp, so a local user who can guess the PID ahead of boot could plant a symlink at that path and cause the watchdog to truncate/overwrite an arbitrary file the app user can write, and the pgrep PID output is briefly world-readable (0644). Prefer creating the file with mktemp (gives 0600 perms and a non-guessable name) instead of a predictable decocms-anchor-<pid> path. Note this is safe w.r.t. the subshell concern: mktemp runs once at script startup before the enumeration loops, and its transient subshell exits before any pgrep pass.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/harness/src/watchdog.rs, line 55:

<comment>The new members_file is written to a fixed, guessable path (`${TMPDIR:-/tmp}/decocms-anchor-$$`) with plain `>` truncation. On Linux this usually resolves to world-writable `/tmp`, so a local user who can guess the PID ahead of boot could plant a symlink at that path and cause the watchdog to truncate/overwrite an arbitrary file the app user can write, and the pgrep PID output is briefly world-readable (0644). Prefer creating the file with `mktemp` (gives 0600 perms and a non-guessable name) instead of a predictable `decocms-anchor-<pid>` path. Note this is safe w.r.t. the subshell concern: mktemp runs once at script startup before the enumeration loops, and its transient subshell exits before any `pgrep` pass.</comment>

<file context>
@@ -24,55 +24,75 @@
+# BSD `pgrep` omits its ancestors, which hides the subshell and is why macOS
+# never showed it. A file keeps the enumeration free of any process this
+# script creates to read it.
+members_file="${TMPDIR:-/tmp}/decocms-anchor-$$"
+trap 'rm -f "$members_file"' EXIT
+
</file context>

[cubic-dev-ai]

P3: The comment describes the negative-PID failure mode incorrectly: kill -KILL -<pid> targets only process group <pid>, and a missing group fails rather than signaling the test binary. Rewording this explanation would prevent future debugging and safety decisions from relying on impossible Linux behavior.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/local-api/src/process_group.rs, line 700:

<comment>The comment describes the negative-PID failure mode incorrectly: `kill -KILL -<pid>` targets only process group `<pid>`, and a missing group fails rather than signaling the test binary. Rewording this explanation would prevent future debugging and safety decisions from relying on impossible Linux behavior.</comment>

<file context>
@@ -697,8 +697,25 @@ mod tests {
         assert!(control.signal(KillSignal::Term).await);
         assert!(IGNORED_SIGNALS.load(Ordering::SeqCst) >= 2);
 
+        // `kill -KILL -<id>` means "the process group with that id". If the
+        // fixture's `process_group(0)` has not taken effect yet, no group owns
+        // `pid` and the signal lands wherever the kernel says that id belongs —
</file context>

Suggested change

	// `kill -KILL -<id>` means "the process group with that id". If the
	// fixture's `process_group(0)` has not taken effect yet, no group owns
	// `pid` and the signal lands wherever the kernel says that id belongs —
	// on Linux this reaped the test binary itself while the fixture lived
	// on as an orphan. Only address the group once the fixture is provably
	// its own leader; otherwise fall back to the pid.
	// A negative kill target addresses the process group whose ID is the
	// absolute value. Verify that the child owns that PGID before using it;
	// otherwise fall back to the direct child PID.

[cubic-dev-ai]

P3: When ps is unavailable or unparsable, this fallback kills only the shell leader, so the sh -c "sleep 30" fixture can leave its separate sleep child running for 30 seconds even though the cleanup task completes. A direct sleep fixture or explicit descendant cleanup would keep the test from leaking processes on Unix environments without a usable ps.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/local-api/src/process_group.rs, line 712:

<comment>When `ps` is unavailable or unparsable, this fallback kills only the shell leader, so the `sh -c "sleep 30"` fixture can leave its separate `sleep` child running for 30 seconds even though the cleanup task completes. A direct `sleep` fixture or explicit descendant cleanup would keep the test from leaking processes on Unix environments without a usable `ps`.</comment>

<file context>
@@ -697,8 +697,25 @@ mod tests {
+            .ok()
+            .and_then(|out| String::from_utf8(out.stdout).ok())
+            .is_some_and(|out| out.trim().parse::<u32>() == Ok(pid));
+        let target = if leads_own_group {
+            format!("-{pid}")
+        } else {
</file context>

[cubic-dev-ai]

6 issues found across 37 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="apps/native/src-tauri/selftest/bundle.js">

<violation number="1" location="apps/native/src-tauri/selftest/bundle.js:584">
P3: The new comment states `remoteImageLoads` is deliberately not gating, but the file header (point (e), ~line 32) still documents the img load as an assertion that is gating: "...and asserts it loads, PLUS asserts `__BOOT_ERRORS` recorded zero `securitypolicyviolation` events ... -- both gating." After this change only `noCspViolations` gates; the header now misdescribes the selftest's pass/fail behavior. Update the header to match so future readers don't think the remote image load can still fail the boot smoke.</violation>
</file>

<file name="apps/native/crates/local-api/src/routes/git.rs">

<violation number="1" location="apps/native/crates/local-api/src/routes/git.rs:2239">
P3: The new comment's mechanism ('20 TERM rounds at 50ms — a full second') doesn't match the actual escalation implemented here: git.rs uses a single TERM with GIT_TERM_GRACE=500ms before one KILL round, and the test's sweep passes a 40ms term grace. The qualitative point (the ~1s budget was too tight on Linux) is right, but the specific round/timing claim is inaccurate and could mislead a future debugger. Suggest restating the comment to reference the real 500ms TERM grace / escalation window.</violation>
</file>

<file name="apps/native/crates/local-api/src/process_group.rs">

<violation number="1" location="apps/native/crates/local-api/src/process_group.rs:712">
P3: When `ps` cannot prove the process group, this fallback kills only the shell and can leave the fixture's `sleep 30` descendant orphaned while the test still passes. Failing the fixture when its own process group cannot be verified, or explicitly cleaning up descendants in the fallback, would avoid leaking processes.</violation>
</file>

<file name="apps/native/crates/harness/src/watchdog.rs">

<violation number="1" location="apps/native/crates/harness/src/watchdog.rs:55">
P2: The watchdog can overwrite an arbitrary file writable by its user if another local process pre-creates the predictable `/tmp/decocms-anchor-<pid>` path as a symlink, because each enumeration uses truncating redirection. Securely create the members file atomically (and preserve the fail-closed behavior if creation fails) before installing the cleanup trap.</violation>
</file>

<file name=".github/workflows/native.yml">

<violation number="1" location=".github/workflows/native.yml:305">
P2: The Linux test leg can be terminated before it completes on a cold runner: this step is capped at 25 minutes, while the workflow documents cold Linux cargo tests taking 25–35 minutes. Raising the step cap to the existing 60-minute job limit would avoid turning expected cold-cache work into a CI failure.</violation>

<violation number="2" location=".github/workflows/native.yml:802">
P1: A failure in `changes` can make `rust-checks-os` skipped, but this branch treats `skipped` as success, so the required `rust-checks` check passes without running either Linux or macOS leg. The same pattern is copied by `contract-suite` and `tauri-build`; checking `needs.changes.result == 'success'` before accepting a skipped matrix would preserve path-based skips without allowing a failed gate through.</violation>
</file>

<sub>Tip: cubic can generate docs of your entire codebase and keep them up to date. Try it here.

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: A failure in changes can make rust-checks-os skipped, but this branch treats skipped as success, so the required rust-checks check passes without running either Linux or macOS leg. The same pattern is copied by contract-suite and tauri-build; checking needs.changes.result == 'success' before accepting a skipped matrix would preserve path-based skips without allowing a failed gate through.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/native.yml, line 802:

<comment>A failure in `changes` can make `rust-checks-os` skipped, but this branch treats `skipped` as success, so the required `rust-checks` check passes without running either Linux or macOS leg. The same pattern is copied by `contract-suite` and `tauri-build`; checking `needs.changes.result == 'success'` before accepting a skipped matrix would preserve path-based skips without allowing a failed gate through.</comment>

<file context>
@@ -561,3 +785,54 @@ jobs:
+      - name: Verify rust-checks legs
+        run: |
+          case "${{ needs.rust-checks-os.result }}" in
+            success|skipped) echo "rust-checks: ${{ needs.rust-checks-os.result }}"; exit 0 ;;
+            *) echo "rust-checks: ${{ needs.rust-checks-os.result }}"; exit 1 ;;
+          esac
</file context>

[cubic-dev-ai]

P2: The watchdog can overwrite an arbitrary file writable by its user if another local process pre-creates the predictable /tmp/decocms-anchor-<pid> path as a symlink, because each enumeration uses truncating redirection. Securely create the members file atomically (and preserve the fail-closed behavior if creation fails) before installing the cleanup trap.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/harness/src/watchdog.rs, line 55:

<comment>The watchdog can overwrite an arbitrary file writable by its user if another local process pre-creates the predictable `/tmp/decocms-anchor-<pid>` path as a symlink, because each enumeration uses truncating redirection. Securely create the members file atomically (and preserve the fail-closed behavior if creation fails) before installing the cleanup trap.</comment>

<file context>
@@ -24,55 +24,75 @@
+# BSD `pgrep` omits its ancestors, which hides the subshell and is why macOS
+# never showed it. A file keeps the enumeration free of any process this
+# script creates to read it.
+members_file="${TMPDIR:-/tmp}/decocms-anchor-$$"
+trap 'rm -f "$members_file"' EXIT
+
</file context>

Suggested change

	members_file="${TMPDIR:-/tmp}/decocms-anchor-$$"
	members_file="$(mktemp "${TMPDIR:-/tmp}/decocms-anchor-XXXXXX")" || while :; do sleep 60; done

[cubic-dev-ai]

P2: The Linux test leg can be terminated before it completes on a cold runner: this step is capped at 25 minutes, while the workflow documents cold Linux cargo tests taking 25–35 minutes. Raising the step cap to the existing 60-minute job limit would avoid turning expected cold-cache work into a CI failure.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/native.yml, line 305:

<comment>The Linux test leg can be terminated before it completes on a cold runner: this step is capped at 25 minutes, while the workflow documents cold Linux cargo tests taking 25–35 minutes. Raising the step cap to the existing 60-minute job limit would avoid turning expected cold-cache work into a CI failure.</comment>

<file context>
@@ -196,13 +272,56 @@ jobs:
+      - name: cargo test (Linux)
+        if: runner.os == 'Linux' && matrix.task != 'lint'
+        working-directory: apps/native
+        timeout-minutes: 25
+        env:
+          CARGO_BUILD_JOBS: "2"
</file context>

Suggested change

	timeout-minutes: 25
	timeout-minutes: 60

[cubic-dev-ai]

P3: The new comment states remoteImageLoads is deliberately not gating, but the file header (point (e), ~line 32) still documents the img load as an assertion that is gating: "...and asserts it loads, PLUS asserts __BOOT_ERRORS recorded zero securitypolicyviolation events ... -- both gating." After this change only noCspViolations gates; the header now misdescribes the selftest's pass/fail behavior. Update the header to match so future readers don't think the remote image load can still fail the boot smoke.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/src-tauri/selftest/bundle.js, line 584:

<comment>The new comment states `remoteImageLoads` is deliberately not gating, but the file header (point (e), ~line 32) still documents the img load as an assertion that is gating: "...and asserts it loads, PLUS asserts `__BOOT_ERRORS` recorded zero `securitypolicyviolation` events ... -- both gating." After this change only `noCspViolations` gates; the header now misdescribes the selftest's pass/fail behavior. Update the header to match so future readers don't think the remote image load can still fail the boot smoke.</comment>

<file context>
@@ -581,7 +581,13 @@
     results.authStatusInvoke,
     results.domMountedEarly,
-    results.remoteImageLoads,
+    // remoteImageLoads is deliberately NOT gating: it fetches a real asset
+    // over the public internet, so a runner with no egress fails it for
+    // reasons that say nothing about this app. The property it exists to
</file context>

[cubic-dev-ai]

P3: The new comment's mechanism ('20 TERM rounds at 50ms — a full second') doesn't match the actual escalation implemented here: git.rs uses a single TERM with GIT_TERM_GRACE=500ms before one KILL round, and the test's sweep passes a 40ms term grace. The qualitative point (the ~1s budget was too tight on Linux) is right, but the specific round/timing claim is inaccurate and could mislead a future debugger. Suggest restating the comment to reference the real 500ms TERM grace / escalation window.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/local-api/src/routes/git.rs, line 2239:

<comment>The new comment's mechanism ('20 TERM rounds at 50ms — a full second') doesn't match the actual escalation implemented here: git.rs uses a single TERM with GIT_TERM_GRACE=500ms before one KILL round, and the test's sweep passes a 40ms term grace. The qualitative point (the ~1s budget was too tight on Linux) is right, but the specific round/timing claim is inaccurate and could mislead a future debugger. Suggest restating the comment to reference the real 500ms TERM grace / escalation window.</comment>

<file context>
@@ -2236,9 +2236,13 @@ mod tests {
             .is_ok_and(|status| status.success())
     }
 
+    /// The budget has to clear the anchor's own escalation, not just "a
+    /// moment": it runs up to 20 TERM rounds at 50ms — a full second — before
+    /// it starts KILL rounds at all. A 1s deadline was therefore exactly the
</file context>

Suggested change

	/// The budget has to clear the anchor's own escalation, not just "a
	/// moment": it runs up to 20 TERM rounds at 50ms — a full second — before
	/// it starts KILL rounds at all. A 1s deadline was therefore exactly the
	/// escalation time, which macOS won and Linux lost.
	/// The budget has to clear the anchor's own escalation, not just "a
	/// moment": git sends TERM and waits GIT_TERM_GRACE (500ms) for the group
	/// to join before escalating to KILL. A 1s deadline was therefore barely
	/// above the escalation time, which macOS won and Linux lost.

[cubic-dev-ai]

P3: When ps cannot prove the process group, this fallback kills only the shell and can leave the fixture's sleep 30 descendant orphaned while the test still passes. Failing the fixture when its own process group cannot be verified, or explicitly cleaning up descendants in the fallback, would avoid leaking processes.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/local-api/src/process_group.rs, line 712:

<comment>When `ps` cannot prove the process group, this fallback kills only the shell and can leave the fixture's `sleep 30` descendant orphaned while the test still passes. Failing the fixture when its own process group cannot be verified, or explicitly cleaning up descendants in the fallback, would avoid leaking processes.</comment>

<file context>
@@ -697,8 +697,25 @@ mod tests {
+            .ok()
+            .and_then(|out| String::from_utf8(out.stdout).ok())
+            .is_some_and(|out| out.trim().parse::<u32>() == Ok(pid));
+        let target = if leads_own_group {
+            format!("-{pid}")
+        } else {
</file context>

[cubic-dev-ai]

6 issues found across 37 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name=".github/workflows/native.yml">

<violation number="1" location=".github/workflows/native.yml:305">
P2: The Linux test leg can fail at its own 25-minute step timeout before the full suite completes. The surrounding measurements already put cold-cache test work at 25–35 minutes, so retaining the 60-minute job budget for this step would avoid a timeout-induced red CI leg.</violation>

<violation number="2" location=".github/workflows/native.yml:802">
P1: A failed `changes` gate can currently make all three required checks pass without running their OS legs. The aggregators should require `needs.changes.result == 'success'` when accepting a skipped matrix, rather than treating every `skipped` result as an irrelevant-path success.</violation>
</file>

<file name="apps/native/crates/local-api/src/process_group.rs">

<violation number="1" location="apps/native/crates/local-api/src/process_group.rs:706">
P2: On Unix hosts without a usable `ps`, the new fallback kills only the direct fixture PID rather than the process group, so this test can leave its `sleep 30` descendant running while `cleanup` still completes. A platform-native process-group query or a fixture that cannot create a descendant would keep the test portable and leak-free.</violation>
</file>

<file name="apps/native/crates/local-api/src/routes/git.rs">

<violation number="1" location="apps/native/crates/local-api/src/routes/git.rs:2160">
P2: This test now runs only on macOS, yet per the comment above it the core assertion is vacuous there: git is not its own group leader on macOS, so `kill -0 -<pid>` fails immediately and `assert_process_group_gone` returns without checking anything real. Meanwhile the platform where group-reaping actually matters (Linux) is where the test is now `#[ignore]`-ed. Net effect: the group-reaped proof has essentially zero active coverage after this change. Consider tracking the Linux teardown divergence as a tracked follow-up (with the `ps -o pid,pgid,comm` repro the comment calls for) rather than a silent `#[cfg_attr(target_os = "linux", ignore)]`, so the reaping behavior isn't left permanently unverified.</violation>
</file>

<file name="apps/native/crates/harness/src/watchdog.rs">

<violation number="1" location="apps/native/crates/harness/src/watchdog.rs:55">
P2: Crash cleanup can be stalled before any child is reaped when a predictable `members_file` path is pre-created in `TMPDIR`: the `>` redirection follows symlinks and blocks on FIFOs, so the anchor can overwrite an unintended file or hang when EOF triggers teardown. Creating the path with an exclusive temporary-file primitive before installing the trap avoids this.</violation>
</file>

<file name="apps/native/src-tauri/selftest/bundle.js">

<violation number="1" location="apps/native/src-tauri/selftest/bundle.js:584">
P3: The header comment for this self-test still describes the remote-image probe as gating ("...and asserts [the remote img] loads ... — both gating"), but this change removes `remoteImageLoads` from the `gating` array. The header now contradicts the code and would mislead someone debugging whether the GitHub-login icon URL actually has to load for `allPass`. Consider updating bullet (e) to note that `remoteImageLoads` is reported but not gating (network-dependent), and that the CSP-protection it existed to assert is still enforced via `noCspViolations`.</violation>
</file>

<sub>Tip: cubic can generate docs of your entire codebase and keep them up to date. Try it here.

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: A failed changes gate can currently make all three required checks pass without running their OS legs. The aggregators should require needs.changes.result == 'success' when accepting a skipped matrix, rather than treating every skipped result as an irrelevant-path success.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/native.yml, line 802:

<comment>A failed `changes` gate can currently make all three required checks pass without running their OS legs. The aggregators should require `needs.changes.result == 'success'` when accepting a skipped matrix, rather than treating every `skipped` result as an irrelevant-path success.</comment>

<file context>
@@ -561,3 +785,54 @@ jobs:
+      - name: Verify rust-checks legs
+        run: |
+          case "${{ needs.rust-checks-os.result }}" in
+            success|skipped) echo "rust-checks: ${{ needs.rust-checks-os.result }}"; exit 0 ;;
+            *) echo "rust-checks: ${{ needs.rust-checks-os.result }}"; exit 1 ;;
+          esac
</file context>

[cubic-dev-ai]

P2: The Linux test leg can fail at its own 25-minute step timeout before the full suite completes. The surrounding measurements already put cold-cache test work at 25–35 minutes, so retaining the 60-minute job budget for this step would avoid a timeout-induced red CI leg.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/native.yml, line 305:

<comment>The Linux test leg can fail at its own 25-minute step timeout before the full suite completes. The surrounding measurements already put cold-cache test work at 25–35 minutes, so retaining the 60-minute job budget for this step would avoid a timeout-induced red CI leg.</comment>

<file context>
@@ -196,13 +272,56 @@ jobs:
+      - name: cargo test (Linux)
+        if: runner.os == 'Linux' && matrix.task != 'lint'
+        working-directory: apps/native
+        timeout-minutes: 25
+        env:
+          CARGO_BUILD_JOBS: "2"
</file context>

Suggested change

	timeout-minutes: 25
	timeout-minutes: 60

[cubic-dev-ai]

P2: On Unix hosts without a usable ps, the new fallback kills only the direct fixture PID rather than the process group, so this test can leave its sleep 30 descendant running while cleanup still completes. A platform-native process-group query or a fixture that cannot create a descendant would keep the test portable and leak-free.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/local-api/src/process_group.rs, line 706:

<comment>On Unix hosts without a usable `ps`, the new fallback kills only the direct fixture PID rather than the process group, so this test can leave its `sleep 30` descendant running while `cleanup` still completes. A platform-native process-group query or a fixture that cannot create a descendant would keep the test portable and leak-free.</comment>

<file context>
@@ -697,8 +697,25 @@ mod tests {
+        // on Linux this reaped the test binary itself while the fixture lived
+        // on as an orphan. Only address the group once the fixture is provably
+        // its own leader; otherwise fall back to the pid.
+        let leads_own_group = std::process::Command::new("ps")
+            .args(["-o", "pgid=", "-p", &pid.to_string()])
+            .output()
</file context>

[cubic-dev-ai]

P2: This test now runs only on macOS, yet per the comment above it the core assertion is vacuous there: git is not its own group leader on macOS, so kill -0 -<pid> fails immediately and assert_process_group_gone returns without checking anything real. Meanwhile the platform where group-reaping actually matters (Linux) is where the test is now #[ignore]-ed. Net effect: the group-reaped proof has essentially zero active coverage after this change. Consider tracking the Linux teardown divergence as a tracked follow-up (with the ps -o pid,pgid,comm repro the comment calls for) rather than a silent #[cfg_attr(target_os = "linux", ignore)], so the reaping behavior isn't left permanently unverified.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/local-api/src/routes/git.rs, line 2160:

<comment>This test now runs only on macOS, yet per the comment above it the core assertion is vacuous there: git is not its own group leader on macOS, so `kill -0 -<pid>` fails immediately and `assert_process_group_gone` returns without checking anything real. Meanwhile the platform where group-reaping actually matters (Linux) is where the test is now `#[ignore]`-ed. Net effect: the group-reaped proof has essentially zero active coverage after this change. Consider tracking the Linux teardown divergence as a tracked follow-up (with the `ps -o pid,pgid,comm` repro the comment calls for) rather than a silent `#[cfg_attr(target_os = "linux", ignore)]`, so the reaping behavior isn't left permanently unverified.</comment>

<file context>
@@ -2140,6 +2140,24 @@ mod tests {
+    /// The sibling assertions the test makes about the sweep itself
+    /// (`term_signaled`/`kill_signaled`/`remaining`) all PASS on Linux — it is
+    /// specifically the "group is gone" proof that does not hold.
+    #[cfg_attr(target_os = "linux", ignore)]
     #[cfg(unix)]
     #[tokio::test]
</file context>

[cubic-dev-ai]

P2: Crash cleanup can be stalled before any child is reaped when a predictable members_file path is pre-created in TMPDIR: the > redirection follows symlinks and blocks on FIFOs, so the anchor can overwrite an unintended file or hang when EOF triggers teardown. Creating the path with an exclusive temporary-file primitive before installing the trap avoids this.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/harness/src/watchdog.rs, line 55:

<comment>Crash cleanup can be stalled before any child is reaped when a predictable `members_file` path is pre-created in `TMPDIR`: the `>` redirection follows symlinks and blocks on FIFOs, so the anchor can overwrite an unintended file or hang when EOF triggers teardown. Creating the path with an exclusive temporary-file primitive before installing the trap avoids this.</comment>

<file context>
@@ -24,55 +24,75 @@
+# BSD `pgrep` omits its ancestors, which hides the subshell and is why macOS
+# never showed it. A file keeps the enumeration free of any process this
+# script creates to read it.
+members_file="${TMPDIR:-/tmp}/decocms-anchor-$$"
+trap 'rm -f "$members_file"' EXIT
+
</file context>

[cubic-dev-ai]

P3: The header comment for this self-test still describes the remote-image probe as gating ("...and asserts [the remote img] loads ... — both gating"), but this change removes remoteImageLoads from the gating array. The header now contradicts the code and would mislead someone debugging whether the GitHub-login icon URL actually has to load for allPass. Consider updating bullet (e) to note that remoteImageLoads is reported but not gating (network-dependent), and that the CSP-protection it existed to assert is still enforced via noCspViolations.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/src-tauri/selftest/bundle.js, line 584:

<comment>The header comment for this self-test still describes the remote-image probe as gating ("...and asserts [the remote img] loads ... — both gating"), but this change removes `remoteImageLoads` from the `gating` array. The header now contradicts the code and would mislead someone debugging whether the GitHub-login icon URL actually has to load for `allPass`. Consider updating bullet (e) to note that `remoteImageLoads` is reported but not gating (network-dependent), and that the CSP-protection it existed to assert is still enforced via `noCspViolations`.</comment>

<file context>
@@ -581,7 +581,13 @@
     results.authStatusInvoke,
     results.domMountedEarly,
-    results.remoteImageLoads,
+    // remoteImageLoads is deliberately NOT gating: it fetches a real asset
+    // over the public internet, so a runner with no egress fails it for
+    // reasons that say nothing about this app. The property it exists to
</file context>

[cubic-dev-ai]

6 issues found across 37 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="apps/native/crates/local-api/src/routes/git.rs">

<violation number="1" location="apps/native/crates/local-api/src/routes/git.rs:2160">
P2: This test is the only tripwire proving TCP/admission git workloads are fully reaped (process group gone) after a shutdown sweep, and the PR now `#[ignore]`s it exactly on Linux where it fails. The test's own comment reads 'something in this group outlives the sweep' — that scenario, if it holds in production, means orphaned git child processes can survive app shutdown on Linux, and ignoring it removes regression detection on the very platform this PR ships. Consider either landing it as `#[ignore]` with a linked tracking issue, or splitting the group-reaping assertion into a Linux-only test that documents the expected group topology, so the failure stays visible and gets fixed rather than silently vanishing from CI.</violation>
</file>

<file name="apps/native/crates/local-api/src/process_group.rs">

<violation number="1" location="apps/native/crates/local-api/src/process_group.rs:712">
P3: This fallback can make the Unix test pass while leaking the fixture's descendant whenever `ps` is unavailable or its output cannot be parsed. The test could use a direct `sleep` child or treat failure to verify the process group as an unavailable test environment instead of silently downgrading group cleanup to PID cleanup.</violation>
</file>

<file name="apps/native/crates/local-api/src/setup/dev.rs">

<violation number="1" location="apps/native/crates/local-api/src/setup/dev.rs:1010">
P2: Linux CI now skips both live process-group tests, so a green Ubuntu leg can miss regressions in the Linux `observe_process_group` and `reap_persisted_dev_group` paths. Keeping these in an isolated Linux job, or replacing them with a non-self-terminating process-group harness, would preserve coverage while avoiding the current runner failure.</violation>
</file>

<file name=".github/workflows/native.yml">

<violation number="1" location=".github/workflows/native.yml:802">
P2: A failure in the change-detection job can make all three required aggregators pass: their matrix jobs become `skipped`, and this branch explicitly accepts `skipped` without checking `needs.changes.result`. Including `needs.changes.result == 'success'` in the success condition would prevent a failed gate from being masked.</violation>
</file>

<file name="apps/native/crates/harness/src/watchdog.rs">

<violation number="1" location="apps/native/crates/harness/src/watchdog.rs:55">
P2: The watchdog writes process enumeration through a predictable, shared temporary path, so a pre-existing symlink or file can redirect or corrupt the output. Creating the file with `mktemp` (or an equivalent exclusive/private-file mechanism) would avoid following attacker-controlled paths.</violation>

<violation number="2" location="apps/native/crates/harness/src/watchdog.rs:61">
P1: A failure to open the members file can be mistaken for `pgrep` finding no processes, allowing the watchdog to exit successfully without reaping survivors. Opening the file separately and returning the indeterminate-error path when that open fails would preserve the fail-closed contract.</violation>
</file>

<sub>Tip: cubic can generate docs of your entire codebase and keep them up to date. Try it here.

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: A failure to open the members file can be mistaken for pgrep finding no processes, allowing the watchdog to exit successfully without reaping survivors. Opening the file separately and returning the indeterminate-error path when that open fails would preserve the fail-closed contract.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/harness/src/watchdog.rs, line 61:

<comment>A failure to open the members file can be mistaken for `pgrep` finding no processes, allowing the watchdog to exit successfully without reaping survivors. Opening the file separately and returning the indeterminate-error path when that open fails would preserve the fail-closed contract.</comment>

<file context>
@@ -24,55 +24,75 @@
-while [ "$term_round" -lt 20 ]; do
-  members="$(pgrep -g "$$" . 2>/dev/null)"
+signal_round() {
+  pgrep -g "$$" . > "$members_file" 2>/dev/null
   status=$?
   if [ "$status" -eq 1 ]; then
</file context>

Suggested change

	pgrep -g "$$" . > "$members_file" 2>/dev/null
	status=$?
	if ! exec 3>"$members_file"; then
	return 3
	fi
	pgrep -g "$$" . >&3 2>/dev/null
	status=$?
	exec 3>&-

[cubic-dev-ai]

P2: This test is the only tripwire proving TCP/admission git workloads are fully reaped (process group gone) after a shutdown sweep, and the PR now #[ignore]s it exactly on Linux where it fails. The test's own comment reads 'something in this group outlives the sweep' — that scenario, if it holds in production, means orphaned git child processes can survive app shutdown on Linux, and ignoring it removes regression detection on the very platform this PR ships. Consider either landing it as #[ignore] with a linked tracking issue, or splitting the group-reaping assertion into a Linux-only test that documents the expected group topology, so the failure stays visible and gets fixed rather than silently vanishing from CI.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/local-api/src/routes/git.rs, line 2160:

<comment>This test is the only tripwire proving TCP/admission git workloads are fully reaped (process group gone) after a shutdown sweep, and the PR now `#[ignore]`s it exactly on Linux where it fails. The test's own comment reads 'something in this group outlives the sweep' — that scenario, if it holds in production, means orphaned git child processes can survive app shutdown on Linux, and ignoring it removes regression detection on the very platform this PR ships. Consider either landing it as `#[ignore]` with a linked tracking issue, or splitting the group-reaping assertion into a Linux-only test that documents the expected group topology, so the failure stays visible and gets fixed rather than silently vanishing from CI.</comment>

<file context>
@@ -2140,6 +2140,24 @@ mod tests {
+    /// The sibling assertions the test makes about the sweep itself
+    /// (`term_signaled`/`kill_signaled`/`remaining`) all PASS on Linux — it is
+    /// specifically the "group is gone" proof that does not hold.
+    #[cfg_attr(target_os = "linux", ignore)]
     #[cfg(unix)]
     #[tokio::test]
</file context>

[cubic-dev-ai]

P2: Linux CI now skips both live process-group tests, so a green Ubuntu leg can miss regressions in the Linux observe_process_group and reap_persisted_dev_group paths. Keeping these in an isolated Linux job, or replacing them with a non-self-terminating process-group harness, would preserve coverage while avoiding the current runner failure.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/local-api/src/setup/dev.rs, line 1010:

<comment>Linux CI now skips both live process-group tests, so a green Ubuntu leg can miss regressions in the Linux `observe_process_group` and `reap_persisted_dev_group` paths. Keeping these in an isolated Linux job, or replacing them with a non-self-terminating process-group harness, would preserve coverage while avoiding the current runner failure.</comment>

<file context>
@@ -956,6 +995,19 @@ mod tests {
+    ///
+    /// Everything else in this module, including the pure `resolve_executable`
+    /// and observation-parsing tests, runs on Linux.
+    #[cfg_attr(target_os = "linux", ignore)]
     #[cfg(unix)]
     #[tokio::test]
</file context>

[cubic-dev-ai]

P2: A failure in the change-detection job can make all three required aggregators pass: their matrix jobs become skipped, and this branch explicitly accepts skipped without checking needs.changes.result. Including needs.changes.result == 'success' in the success condition would prevent a failed gate from being masked.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/native.yml, line 802:

<comment>A failure in the change-detection job can make all three required aggregators pass: their matrix jobs become `skipped`, and this branch explicitly accepts `skipped` without checking `needs.changes.result`. Including `needs.changes.result == 'success'` in the success condition would prevent a failed gate from being masked.</comment>

<file context>
@@ -561,3 +785,54 @@ jobs:
+      - name: Verify rust-checks legs
+        run: |
+          case "${{ needs.rust-checks-os.result }}" in
+            success|skipped) echo "rust-checks: ${{ needs.rust-checks-os.result }}"; exit 0 ;;
+            *) echo "rust-checks: ${{ needs.rust-checks-os.result }}"; exit 1 ;;
+          esac
</file context>

[cubic-dev-ai]

P2: The watchdog writes process enumeration through a predictable, shared temporary path, so a pre-existing symlink or file can redirect or corrupt the output. Creating the file with mktemp (or an equivalent exclusive/private-file mechanism) would avoid following attacker-controlled paths.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/harness/src/watchdog.rs, line 55:

<comment>The watchdog writes process enumeration through a predictable, shared temporary path, so a pre-existing symlink or file can redirect or corrupt the output. Creating the file with `mktemp` (or an equivalent exclusive/private-file mechanism) would avoid following attacker-controlled paths.</comment>

<file context>
@@ -24,55 +24,75 @@
+# BSD `pgrep` omits its ancestors, which hides the subshell and is why macOS
+# never showed it. A file keeps the enumeration free of any process this
+# script creates to read it.
+members_file="${TMPDIR:-/tmp}/decocms-anchor-$$"
+trap 'rm -f "$members_file"' EXIT
+
</file context>

Suggested change

	members_file="${TMPDIR:-/tmp}/decocms-anchor-$$"
	members_file="$(mktemp "${TMPDIR:-/tmp}/decocms-anchor-XXXXXX")" || exit 1

[cubic-dev-ai]

P3: This fallback can make the Unix test pass while leaking the fixture's descendant whenever ps is unavailable or its output cannot be parsed. The test could use a direct sleep child or treat failure to verify the process group as an unavailable test environment instead of silently downgrading group cleanup to PID cleanup.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/local-api/src/process_group.rs, line 712:

<comment>This fallback can make the Unix test pass while leaking the fixture's descendant whenever `ps` is unavailable or its output cannot be parsed. The test could use a direct `sleep` child or treat failure to verify the process group as an unavailable test environment instead of silently downgrading group cleanup to PID cleanup.</comment>

<file context>
@@ -697,8 +697,25 @@ mod tests {
+            .ok()
+            .and_then(|out| String::from_utf8(out.stdout).ok())
+            .is_some_and(|out| out.trim().parse::<u32>() == Ok(pid));
+        let target = if leads_own_group {
+            format!("-{pid}")
+        } else {
</file context>

[cubic-dev-ai]

8 issues found across 37 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="apps/native/crates/local-api/src/setup/dev.rs">

<violation number="1" location="apps/native/crates/local-api/src/setup/dev.rs:1010">
P2: Linux CI now skips both live process-group tests, so the new `/proc/<pid>/exe` identity path and persisted-orphan reaping are never executed on the target OS. A Linux-safe fixture or dedicated runner would preserve coverage instead of marking these tests ignored.</violation>
</file>

<file name=".github/workflows/native.yml">

<violation number="1" location=".github/workflows/native.yml:305">
P2: The step-level timeout-minutes: 25 on the Linux cargo-test step is tighter than the job's 60-minute budget, and the workflow's own notes say a cold-cache full build+run previously landed in the 25-35 min range. If the debug-info reduction doesn't bring it comfortably under 25 minutes on a cold cache, the step will fail via hard timeout even though the memory-kill it targets is gone — reintroducing a distinct flakiness mode. Consider raising the step timeout to keep the step from being the binding constraint (or verify with a fresh, empty cache that 25 minutes reliably suffices).</violation>

<violation number="2" location=".github/workflows/native.yml:318">
P3: The setup:: chunk overlaps with routes::setup:: tests. Since routes/mod.rs declares `pub mod setup`, the substring filters cause the routes::setup:: subtree to be run twice — once by the routes:: chunk and once by the setup:: chunk — on the Linux test leg that is already the slowest. This is redundant work, not a correctness failure. Consider selecting chunks by top-level module (e.g. use `--exact`-style filters or route each top-level module to its own invocation) to avoid the overlap, or accept the minor duplicate runtime.</violation>

<violation number="3" location=".github/workflows/native.yml:801">
P1: A failure in the changes detector can make the required native check pass: `if: always()` still runs this aggregator, the dependent matrix is skipped, and `skipped` is accepted without checking `needs.changes.result`. Checking that `changes` succeeded before accepting a skipped matrix (and applying the same guard to `contract-suite` and `tauri-build`) would prevent a broken or empty gate from bypassing branch protection.</violation>
</file>

<file name="apps/native/crates/harness/src/watchdog.rs">

<violation number="1" location="apps/native/crates/harness/src/watchdog.rs:55">
P1: The watchdog's enumeration file is vulnerable to a predictable-name symlink race, so a local process can make the cleanup path look empty and release the restart fence while group members remain. Creating the file atomically with `mktemp` (and parking fail-closed if creation fails) would avoid following an attacker-created path.</violation>

<violation number="2" location="apps/native/crates/harness/src/watchdog.rs:61">
P1: A failed output-file open can be misclassified as `pgrep`'s no-match status, causing the anchor to exit successfully instead of failing closed when the temp directory/file becomes unavailable. Open the file on a dedicated descriptor first and send `pgrep` output through that descriptor so status 1 is only accepted from a completed `pgrep` invocation.</violation>
</file>

<file name="apps/native/crates/local-api/src/routes/git.rs">

<violation number="1" location="apps/native/crates/local-api/src/routes/git.rs:2263">
P3: The 1s→15s timeout increase on `assert_process_group_gone`/`assert_process_gone` is justified in the added comment as addressing the Linux teardown failure ("macOS won and Linux lost"), but the only test that calls these helpers — `slow_git_group_is_term_kill_reaped_before_owner_finalizes` — is simultaneously marked `#[cfg_attr(target_os = "linux", ignore)]` in this same change. On Linux the 15s budget never executes, so the increase has no effect on the platform it was written for; it only gives macOS (where the test already passed at 1s) extra headroom. The real Linux group-reap issue, and the production watchdog/group-reap path this PR is meant to enable, therefore remains unverified on its target platform. Consider either not ignoring this test on Linux (watching it with `ps -o pid,pgid,comm` during the sweep, as the comment suggests) or adjusting the comment so it doesn't claim the budget addresses the Linux run it never applies to.</violation>
</file>

<file name="apps/native/src-tauri/selftest/bundle.js">

<violation number="1" location="apps/native/src-tauri/selftest/bundle.js:584">
P3: The change itself is correct and the new inline comment is accurate, but it now contradicts the file-header contract description. Section (e) of the header block (lines ~25-30) still states that the remote-image probe and the `securitypolicyviolation` capture are "both gating", whereas `remoteImageLoads` is now informational-only while `noCspViolations` gates. A future maintainer relying on that header would be misled about what actually fails the self-test. Update the header's section (e) wording to note that the remote-image load is informational/reported while the CSP violation count is what gates.</violation>
</file>

<sub>Tip: cubic can generate docs of your entire codebase and keep them up to date. Try it here.

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: A failure in the changes detector can make the required native check pass: if: always() still runs this aggregator, the dependent matrix is skipped, and skipped is accepted without checking needs.changes.result. Checking that changes succeeded before accepting a skipped matrix (and applying the same guard to contract-suite and tauri-build) would prevent a broken or empty gate from bypassing branch protection.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/native.yml, line 801:

<comment>A failure in the changes detector can make the required native check pass: `if: always()` still runs this aggregator, the dependent matrix is skipped, and `skipped` is accepted without checking `needs.changes.result`. Checking that `changes` succeeded before accepting a skipped matrix (and applying the same guard to `contract-suite` and `tauri-build`) would prevent a broken or empty gate from bypassing branch protection.</comment>

<file context>
@@ -561,3 +785,54 @@ jobs:
+    steps:
+      - name: Verify rust-checks legs
+        run: |
+          case "${{ needs.rust-checks-os.result }}" in
+            success|skipped) echo "rust-checks: ${{ needs.rust-checks-os.result }}"; exit 0 ;;
+            *) echo "rust-checks: ${{ needs.rust-checks-os.result }}"; exit 1 ;;
</file context>

[cubic-dev-ai]

P1: The watchdog's enumeration file is vulnerable to a predictable-name symlink race, so a local process can make the cleanup path look empty and release the restart fence while group members remain. Creating the file atomically with mktemp (and parking fail-closed if creation fails) would avoid following an attacker-created path.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/harness/src/watchdog.rs, line 55:

<comment>The watchdog's enumeration file is vulnerable to a predictable-name symlink race, so a local process can make the cleanup path look empty and release the restart fence while group members remain. Creating the file atomically with `mktemp` (and parking fail-closed if creation fails) would avoid following an attacker-created path.</comment>

<file context>
@@ -24,55 +24,75 @@
+# BSD `pgrep` omits its ancestors, which hides the subshell and is why macOS
+# never showed it. A file keeps the enumeration free of any process this
+# script creates to read it.
+members_file="${TMPDIR:-/tmp}/decocms-anchor-$$"
+trap 'rm -f "$members_file"' EXIT
+
</file context>

Suggested change

	members_file="${TMPDIR:-/tmp}/decocms-anchor-$$"
	members_file="$(mktemp "${TMPDIR:-/tmp}/decocms-anchor-XXXXXX")" || { while :; do sleep 60; done; }

[cubic-dev-ai]

P1: A failed output-file open can be misclassified as pgrep's no-match status, causing the anchor to exit successfully instead of failing closed when the temp directory/file becomes unavailable. Open the file on a dedicated descriptor first and send pgrep output through that descriptor so status 1 is only accepted from a completed pgrep invocation.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/harness/src/watchdog.rs, line 61:

<comment>A failed output-file open can be misclassified as `pgrep`'s no-match status, causing the anchor to exit successfully instead of failing closed when the temp directory/file becomes unavailable. Open the file on a dedicated descriptor first and send `pgrep` output through that descriptor so status 1 is only accepted from a completed `pgrep` invocation.</comment>

<file context>
@@ -24,55 +24,75 @@
-while [ "$term_round" -lt 20 ]; do
-  members="$(pgrep -g "$$" . 2>/dev/null)"
+signal_round() {
+  pgrep -g "$$" . > "$members_file" 2>/dev/null
   status=$?
   if [ "$status" -eq 1 ]; then
</file context>

Suggested change

	pgrep -g "$$" . > "$members_file" 2>/dev/null
	status=$?
	if ! exec 3>"$members_file"; then return 3; fi
	pgrep -g "$$" . >&3 2>/dev/null
	status=$?
	exec 3>&-

[cubic-dev-ai]

P2: Linux CI now skips both live process-group tests, so the new /proc/<pid>/exe identity path and persisted-orphan reaping are never executed on the target OS. A Linux-safe fixture or dedicated runner would preserve coverage instead of marking these tests ignored.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/local-api/src/setup/dev.rs, line 1010:

<comment>Linux CI now skips both live process-group tests, so the new `/proc/<pid>/exe` identity path and persisted-orphan reaping are never executed on the target OS. A Linux-safe fixture or dedicated runner would preserve coverage instead of marking these tests ignored.</comment>

<file context>
@@ -956,6 +995,19 @@ mod tests {
+    ///
+    /// Everything else in this module, including the pure `resolve_executable`
+    /// and observation-parsing tests, runs on Linux.
+    #[cfg_attr(target_os = "linux", ignore)]
     #[cfg(unix)]
     #[tokio::test]
</file context>

[cubic-dev-ai]

P2: The step-level timeout-minutes: 25 on the Linux cargo-test step is tighter than the job's 60-minute budget, and the workflow's own notes say a cold-cache full build+run previously landed in the 25-35 min range. If the debug-info reduction doesn't bring it comfortably under 25 minutes on a cold cache, the step will fail via hard timeout even though the memory-kill it targets is gone — reintroducing a distinct flakiness mode. Consider raising the step timeout to keep the step from being the binding constraint (or verify with a fresh, empty cache that 25 minutes reliably suffices).

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/native.yml, line 305:

<comment>The step-level timeout-minutes: 25 on the Linux cargo-test step is tighter than the job's 60-minute budget, and the workflow's own notes say a cold-cache full build+run previously landed in the 25-35 min range. If the debug-info reduction doesn't bring it comfortably under 25 minutes on a cold cache, the step will fail via hard timeout even though the memory-kill it targets is gone — reintroducing a distinct flakiness mode. Consider raising the step timeout to keep the step from being the binding constraint (or verify with a fresh, empty cache that 25 minutes reliably suffices).</comment>

<file context>
@@ -196,13 +272,56 @@ jobs:
+      - name: cargo test (Linux)
+        if: runner.os == 'Linux' && matrix.task != 'lint'
+        working-directory: apps/native
+        timeout-minutes: 25
+        env:
+          CARGO_BUILD_JOBS: "2"
</file context>

Suggested change

	timeout-minutes: 25
	timeout-minutes: 35

[cubic-dev-ai]

P3: The 1s→15s timeout increase on assert_process_group_gone/assert_process_gone is justified in the added comment as addressing the Linux teardown failure ("macOS won and Linux lost"), but the only test that calls these helpers — slow_git_group_is_term_kill_reaped_before_owner_finalizes — is simultaneously marked #[cfg_attr(target_os = "linux", ignore)] in this same change. On Linux the 15s budget never executes, so the increase has no effect on the platform it was written for; it only gives macOS (where the test already passed at 1s) extra headroom. The real Linux group-reap issue, and the production watchdog/group-reap path this PR is meant to enable, therefore remains unverified on its target platform. Consider either not ignoring this test on Linux (watching it with ps -o pid,pgid,comm during the sweep, as the comment suggests) or adjusting the comment so it doesn't claim the budget addresses the Linux run it never applies to.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/local-api/src/routes/git.rs, line 2263:

<comment>The 1s→15s timeout increase on `assert_process_group_gone`/`assert_process_gone` is justified in the added comment as addressing the Linux teardown failure ("macOS won and Linux lost"), but the only test that calls these helpers — `slow_git_group_is_term_kill_reaped_before_owner_finalizes` — is simultaneously marked `#[cfg_attr(target_os = "linux", ignore)]` in this same change. On Linux the 15s budget never executes, so the increase has no effect on the platform it was written for; it only gives macOS (where the test already passed at 1s) extra headroom. The real Linux group-reap issue, and the production watchdog/group-reap path this PR is meant to enable, therefore remains unverified on its target platform. Consider either not ignoring this test on Linux (watching it with `ps -o pid,pgid,comm` during the sweep, as the comment suggests) or adjusting the comment so it doesn't claim the budget addresses the Linux run it never applies to.</comment>

<file context>
@@ -2236,9 +2254,13 @@ mod tests {
     #[cfg(unix)]
     async fn assert_process_group_gone(pid: u32) {
-        tokio::time::timeout(Duration::from_secs(1), async {
+        tokio::time::timeout(Duration::from_secs(15), async {
             while process_exists(format!("-{pid}")) {
                 tokio::task::yield_now().await;
</file context>

[cubic-dev-ai]

P3: The change itself is correct and the new inline comment is accurate, but it now contradicts the file-header contract description. Section (e) of the header block (lines ~25-30) still states that the remote-image probe and the securitypolicyviolation capture are "both gating", whereas remoteImageLoads is now informational-only while noCspViolations gates. A future maintainer relying on that header would be misled about what actually fails the self-test. Update the header's section (e) wording to note that the remote-image load is informational/reported while the CSP violation count is what gates.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/src-tauri/selftest/bundle.js, line 584:

<comment>The change itself is correct and the new inline comment is accurate, but it now contradicts the file-header contract description. Section (e) of the header block (lines ~25-30) still states that the remote-image probe and the `securitypolicyviolation` capture are "both gating", whereas `remoteImageLoads` is now informational-only while `noCspViolations` gates. A future maintainer relying on that header would be misled about what actually fails the self-test. Update the header's section (e) wording to note that the remote-image load is informational/reported while the CSP violation count is what gates.</comment>

<file context>
@@ -581,7 +581,13 @@
     results.authStatusInvoke,
     results.domMountedEarly,
-    results.remoteImageLoads,
+    // remoteImageLoads is deliberately NOT gating: it fetches a real asset
+    // over the public internet, so a runner with no egress fails it for
+    // reasons that say nothing about this app. The property it exists to
</file context>

[cubic-dev-ai]

P3: The setup:: chunk overlaps with routes::setup:: tests. Since routes/mod.rs declares pub mod setup, the substring filters cause the routes::setup:: subtree to be run twice — once by the routes:: chunk and once by the setup:: chunk — on the Linux test leg that is already the slowest. This is redundant work, not a correctness failure. Consider selecting chunks by top-level module (e.g. use --exact-style filters or route each top-level module to its own invocation) to avoid the overlap, or accept the minor duplicate runtime.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/native.yml, line 318:

<comment>The setup:: chunk overlaps with routes::setup:: tests. Since routes/mod.rs declares `pub mod setup`, the substring filters cause the routes::setup:: subtree to be run twice — once by the routes:: chunk and once by the setup:: chunk — on the Linux test leg that is already the slowest. This is redundant work, not a correctness failure. Consider selecting chunks by top-level module (e.g. use `--exact`-style filters or route each top-level module to its own invocation) to avoid the overlap, or accept the minor duplicate runtime.</comment>

<file context>
@@ -196,13 +272,56 @@ jobs:
+          # excluded, which is accumulation, not one bad test. A new process
+          # per chunk reclaims whatever is being held. `setsid` keeps the
+          # process-group suites' stray signals inside their own session.
+          for chunk in routes:: sandbox:: setup::; do
+            setsid --wait cargo test -p local-api "$chunk" -- --test-threads=1
+          done
</file context>

[cubic-dev-ai]

4 issues found across 37 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="apps/native/src-tauri/selftest/bundle.js">

<violation number="1" location="apps/native/src-tauri/selftest/bundle.js:584">
P3: This change removes remoteImageLoads from the app-side allPass gate, but two related sources still treat it as gating: the file-header comment (item e) says remote-image load and noCspViolations are 'both gating', and boot-smoke.ts's gatingKeys Set still labels it FAIL (rather than INFO) — so a no-egress Linux runner will print '[FAIL] remoteImageLoads' while the suite passes. Consider updating the stale header and dropping remoteImageLoads from boot-smoke.ts's gatingKeys so the reporting matches the new non-gating intent, or the misleading output undercuts the whole point of this change.</violation>
</file>

<file name=".github/workflows/native.yml">

<violation number="1" location=".github/workflows/native.yml:801">
P1: A failed `changes` gate can be reported as a passing required check: GitHub skips `rust-checks-os` when its `changes` dependency fails, and this `case` treats that `skipped` result as success. Checking that `needs.changes.result` is `success` in all three aggregators would prevent CI failures from being converted into green required checks.</violation>
</file>

<file name="apps/native/crates/local-api/src/routes/git.rs">

<violation number="1" location="apps/native/crates/local-api/src/routes/git.rs:2238">
P2: The teardown assertion fails open when `pgrep` is unavailable or exits with an error, interpreting an inability to enumerate the group as proof that it is gone. Distinguishing exit 1 from execution/other failures would prevent this test from passing without making its liveness check.</violation>
</file>

<file name="apps/native/crates/local-api/src/process_group.rs">

<violation number="1" location="apps/native/crates/local-api/src/process_group.rs:706">
P2: On Unix installations without `ps`, this fallback sends SIGKILL only to the shell and leaves its `sleep 30` process running, while the test still reports successful cleanup because the unanchored waiter observes only the direct child. The test would be safer using the documented `process_group(0)` group target directly, or treating an unavailable/unparseable PGID probe as a test failure rather than silently weakening cleanup.</violation>
</file>

<sub>Tip: cubic can generate docs of your entire codebase and keep them up to date. Try it here.

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: A failed changes gate can be reported as a passing required check: GitHub skips rust-checks-os when its changes dependency fails, and this case treats that skipped result as success. Checking that needs.changes.result is success in all three aggregators would prevent CI failures from being converted into green required checks.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/native.yml, line 801:

<comment>A failed `changes` gate can be reported as a passing required check: GitHub skips `rust-checks-os` when its `changes` dependency fails, and this `case` treats that `skipped` result as success. Checking that `needs.changes.result` is `success` in all three aggregators would prevent CI failures from being converted into green required checks.</comment>

<file context>
@@ -561,3 +785,54 @@ jobs:
+    steps:
+      - name: Verify rust-checks legs
+        run: |
+          case "${{ needs.rust-checks-os.result }}" in
+            success|skipped) echo "rust-checks: ${{ needs.rust-checks-os.result }}"; exit 0 ;;
+            *) echo "rust-checks: ${{ needs.rust-checks-os.result }}"; exit 1 ;;
</file context>

[cubic-dev-ai]

P2: The teardown assertion fails open when pgrep is unavailable or exits with an error, interpreting an inability to enumerate the group as proof that it is gone. Distinguishing exit 1 from execution/other failures would prevent this test from passing without making its liveness check.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/local-api/src/routes/git.rs, line 2238:

<comment>The teardown assertion fails open when `pgrep` is unavailable or exits with an error, interpreting an inability to enumerate the group as proof that it is gone. Distinguishing exit 1 from execution/other failures would prevent this test from passing without making its liveness check.</comment>

<file context>
@@ -2225,6 +2225,19 @@ mod tests {
+            .stdout(std::process::Stdio::null())
+            .stderr(std::process::Stdio::null())
+            .status()
+            .is_ok_and(|status| status.success())
+    }
+
</file context>

Suggested change

	.is_ok_and(|status| status.success())
	.map(|status| match status.code() {
	Some(0) => true,
	Some(1) => false,
	code => panic!("pgrep failed with {code:?}"),
	})
	.expect("pgrep available")

[cubic-dev-ai]

P2: On Unix installations without ps, this fallback sends SIGKILL only to the shell and leaves its sleep 30 process running, while the test still reports successful cleanup because the unanchored waiter observes only the direct child. The test would be safer using the documented process_group(0) group target directly, or treating an unavailable/unparseable PGID probe as a test failure rather than silently weakening cleanup.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/local-api/src/process_group.rs, line 706:

<comment>On Unix installations without `ps`, this fallback sends SIGKILL only to the shell and leaves its `sleep 30` process running, while the test still reports successful cleanup because the unanchored waiter observes only the direct child. The test would be safer using the documented `process_group(0)` group target directly, or treating an unavailable/unparseable PGID probe as a test failure rather than silently weakening cleanup.</comment>

<file context>
@@ -697,8 +697,25 @@ mod tests {
+        // on Linux this reaped the test binary itself while the fixture lived
+        // on as an orphan. Only address the group once the fixture is provably
+        // its own leader; otherwise fall back to the pid.
+        let leads_own_group = std::process::Command::new("ps")
+            .args(["-o", "pgid=", "-p", &pid.to_string()])
+            .output()
</file context>

[cubic-dev-ai]

P3: This change removes remoteImageLoads from the app-side allPass gate, but two related sources still treat it as gating: the file-header comment (item e) says remote-image load and noCspViolations are 'both gating', and boot-smoke.ts's gatingKeys Set still labels it FAIL (rather than INFO) — so a no-egress Linux runner will print '[FAIL] remoteImageLoads' while the suite passes. Consider updating the stale header and dropping remoteImageLoads from boot-smoke.ts's gatingKeys so the reporting matches the new non-gating intent, or the misleading output undercuts the whole point of this change.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/src-tauri/selftest/bundle.js, line 584:

<comment>This change removes remoteImageLoads from the app-side allPass gate, but two related sources still treat it as gating: the file-header comment (item e) says remote-image load and noCspViolations are 'both gating', and boot-smoke.ts's gatingKeys Set still labels it FAIL (rather than INFO) — so a no-egress Linux runner will print '[FAIL] remoteImageLoads' while the suite passes. Consider updating the stale header and dropping remoteImageLoads from boot-smoke.ts's gatingKeys so the reporting matches the new non-gating intent, or the misleading output undercuts the whole point of this change.</comment>

<file context>
@@ -581,7 +581,13 @@
     results.authStatusInvoke,
     results.domMountedEarly,
-    results.remoteImageLoads,
+    // remoteImageLoads is deliberately NOT gating: it fetches a real asset
+    // over the public internet, so a runner with no egress fails it for
+    // reasons that say nothing about this app. The property it exists to
</file context>

[cubic-dev-ai]

7 issues found across 37 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="apps/native/crates/local-api/src/setup/dev.rs">

<violation number="1" location="apps/native/crates/local-api/src/setup/dev.rs:1012">
P2: The two live process-group tests are skipped in every Linux build, so the Ubuntu CI leg cannot exercise the `/proc` executable-identity and orphan-reaping paths this PR adds. `target_os = "linux"` does not identify GitHub-hosted runners; use a runner-specific test/CI condition instead of suppressing all Linux executions.</violation>
</file>

<file name="apps/native/crates/local-api/src/process_group.rs">

<violation number="1" location="apps/native/crates/local-api/src/process_group.rs:712">
P2: When `ps` is unavailable or its output is not parseable, this fallback kills only the shell PID and can leave the fixture's `sleep 30` descendant running after the test reports success. The fallback should also reliably terminate descendants, or the fixture should avoid spawning a separate child process.</violation>
</file>

<file name="apps/native/crates/local-api/src/routes/git.rs">

<violation number="1" location="apps/native/crates/local-api/src/routes/git.rs:2237">
P2: A missing or failing `pgrep` makes this helper report “group gone” instead of failing the test, allowing the Linux cleanup regression to pass without evidence. Distinguishing exit codes 0/1 and failing on spawn or other statuses would keep this assertion fail-closed.</violation>

<violation number="2" location="apps/native/crates/local-api/src/routes/git.rs:2266">
P2: The group-cleanup assertion checks the wrong identifier: `pid` is the fake Git process PID, while the spawned command's PGID is the independent watchdog's PID. Recording/passing the actual PGID (or resolving the command's PGID) before calling `process_group_exists` would prevent this assertion from returning immediately while another same-group descendant remains alive.</violation>
</file>

<file name=".github/workflows/native.yml">

<violation number="1" location=".github/workflows/native.yml:305">
P2: The `cargo test (Linux)` step carries `timeout-minutes: 25`, but on a cold cache this step both compiles the test-profile binaries (including the GTK/WebKit tree) and runs harness, upstream, four local-api invocations, and deco single-threaded with `CARGO_BUILD_JOBS: 2` capping parallelism. Your own comments in this job say a cold run measured 25-35 min and was killed at ~30 — right at this cap. Since `rust-cache` saves in a post step, a step that times out at 25 min never warms the cache, which recreates exactly the 'every run starts cold' spiral this refactor is meant to eliminate. Consider raising the step timeout (or dropping the step-level cap and relying on the 60-min job timeout), especially for the first run after a cache eviction.</violation>

<violation number="2" location=".github/workflows/native.yml:646">
P1: The Linux build does not load the AppImage overlay: Tauri does not auto-discover this `tauri.linux.conf.json5` name, and this command supplies no `--config`. The base targets remain `app`/`dmg`, so the required AppImage can be missing and the subsequent Linux steps cannot validate or boot it; explicitly pass the overlay on Linux or rename it to the supported platform filename.</violation>

<violation number="3" location=".github/workflows/native.yml:801">
P1: A failed or cancelled `changes` gate can be reported as a passing required check: `always()` still runs the aggregator, the downstream matrix is skipped, and `skipped` is accepted. All three aggregators should also require `needs.changes.result == 'success'` before accepting a skipped matrix, otherwise a PR can merge without running the intended checks.</violation>
</file>

<sub>Tip: cubic can generate docs of your entire codebase and keep them up to date. Try it here.

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: The Linux build does not load the AppImage overlay: Tauri does not auto-discover this tauri.linux.conf.json5 name, and this command supplies no --config. The base targets remain app/dmg, so the required AppImage can be missing and the subsequent Linux steps cannot validate or boot it; explicitly pass the overlay on Linux or rename it to the supported platform filename.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/native.yml, line 646:

<comment>The Linux build does not load the AppImage overlay: Tauri does not auto-discover this `tauri.linux.conf.json5` name, and this command supplies no `--config`. The base targets remain `app`/`dmg`, so the required AppImage can be missing and the subsequent Linux steps cannot validate or boot it; explicitly pass the overlay on Linux or rename it to the supported platform filename.</comment>

<file context>
@@ -466,17 +636,59 @@ jobs:
+        # validate an artifact produced by a different bundler than release.
+        # No `--bundles` flag: macOS takes its targets from
+        # tauri.conf.json5, Linux from the tauri.linux.conf.json5 overlay.
+        run: bunx @tauri-apps/cli@2.11.4 build
+
+      # Runs BEFORE anything extracts the AppImage (the boot smoke does,
</file context>

Suggested change

	run: bunx @tauri-apps/cli@2.11.4 build
	run: |
	if [ "$RUNNER_OS" = "Linux" ]; then
	bunx @tauri-apps/cli@2.11.4 build --config src-tauri/tauri.linux.conf.json5
	else
	bunx @tauri-apps/cli@2.11.4 build
	fi

[cubic-dev-ai]

P1: A failed or cancelled changes gate can be reported as a passing required check: always() still runs the aggregator, the downstream matrix is skipped, and skipped is accepted. All three aggregators should also require needs.changes.result == 'success' before accepting a skipped matrix, otherwise a PR can merge without running the intended checks.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/native.yml, line 801:

<comment>A failed or cancelled `changes` gate can be reported as a passing required check: `always()` still runs the aggregator, the downstream matrix is skipped, and `skipped` is accepted. All three aggregators should also require `needs.changes.result == 'success'` before accepting a skipped matrix, otherwise a PR can merge without running the intended checks.</comment>

<file context>
@@ -561,3 +785,54 @@ jobs:
+    steps:
+      - name: Verify rust-checks legs
+        run: |
+          case "${{ needs.rust-checks-os.result }}" in
+            success|skipped) echo "rust-checks: ${{ needs.rust-checks-os.result }}"; exit 0 ;;
+            *) echo "rust-checks: ${{ needs.rust-checks-os.result }}"; exit 1 ;;
</file context>

[cubic-dev-ai]

P2: The two live process-group tests are skipped in every Linux build, so the Ubuntu CI leg cannot exercise the /proc executable-identity and orphan-reaping paths this PR adds. target_os = "linux" does not identify GitHub-hosted runners; use a runner-specific test/CI condition instead of suppressing all Linux executions.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/local-api/src/setup/dev.rs, line 1012:

<comment>The two live process-group tests are skipped in every Linux build, so the Ubuntu CI leg cannot exercise the `/proc` executable-identity and orphan-reaping paths this PR adds. `target_os = "linux"` does not identify GitHub-hosted runners; use a runner-specific test/CI condition instead of suppressing all Linux executions.</comment>

<file context>
@@ -956,6 +995,21 @@ mod tests {
+    /// So this is a CI-environment exclusion, NOT a gap in the Linux port:
+    /// the behaviour under test is confirmed working on Linux. Re-enable by
+    /// making the runner reap orphans, or by having the anchor skip zombies.
+    #[cfg_attr(target_os = "linux", ignore)]
     #[cfg(unix)]
     #[tokio::test]
</file context>

[cubic-dev-ai]

P2: When ps is unavailable or its output is not parseable, this fallback kills only the shell PID and can leave the fixture's sleep 30 descendant running after the test reports success. The fallback should also reliably terminate descendants, or the fixture should avoid spawning a separate child process.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/local-api/src/process_group.rs, line 712:

<comment>When `ps` is unavailable or its output is not parseable, this fallback kills only the shell PID and can leave the fixture's `sleep 30` descendant running after the test reports success. The fallback should also reliably terminate descendants, or the fixture should avoid spawning a separate child process.</comment>

<file context>
@@ -697,8 +697,25 @@ mod tests {
+            .ok()
+            .and_then(|out| String::from_utf8(out.stdout).ok())
+            .is_some_and(|out| out.trim().parse::<u32>() == Ok(pid));
+        let target = if leads_own_group {
+            format!("-{pid}")
+        } else {
</file context>

[cubic-dev-ai]

P2: A missing or failing pgrep makes this helper report “group gone” instead of failing the test, allowing the Linux cleanup regression to pass without evidence. Distinguishing exit codes 0/1 and failing on spawn or other statuses would keep this assertion fail-closed.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/local-api/src/routes/git.rs, line 2237:

<comment>A missing or failing `pgrep` makes this helper report “group gone” instead of failing the test, allowing the Linux cleanup regression to pass without evidence. Distinguishing exit codes 0/1 and failing on spawn or other statuses would keep this assertion fail-closed.</comment>

<file context>
@@ -2225,6 +2225,19 @@ mod tests {
+            .stdin(std::process::Stdio::null())
+            .stdout(std::process::Stdio::null())
+            .stderr(std::process::Stdio::null())
+            .status()
+            .is_ok_and(|status| status.success())
+    }
</file context>

Suggested change

	.status()
	.is_ok_and(|status| status.success())
	.status()
	.map_or_else(
	|error| panic!("pgrep failed: {error}"),
	|status| match status.code() {
	Some(0) => true,
	Some(1) => false,
	_ => panic!("pgrep exited with {status:?}"),
	},
	)

[cubic-dev-ai]

P2: The group-cleanup assertion checks the wrong identifier: pid is the fake Git process PID, while the spawned command's PGID is the independent watchdog's PID. Recording/passing the actual PGID (or resolving the command's PGID) before calling process_group_exists would prevent this assertion from returning immediately while another same-group descendant remains alive.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/local-api/src/routes/git.rs, line 2266:

<comment>The group-cleanup assertion checks the wrong identifier: `pid` is the fake Git process PID, while the spawned command's PGID is the independent watchdog's PID. Recording/passing the actual PGID (or resolving the command's PGID) before calling `process_group_exists` would prevent this assertion from returning immediately while another same-group descendant remains alive.</comment>

<file context>
@@ -2236,10 +2249,21 @@ mod tests {
-        tokio::time::timeout(Duration::from_secs(1), async {
-            while process_exists(format!("-{pid}")) {
+        tokio::time::timeout(Duration::from_secs(15), async {
+            while process_group_exists(pid) {
                 tokio::task::yield_now().await;
             }
</file context>

[cubic-dev-ai]

P2: The cargo test (Linux) step carries timeout-minutes: 25, but on a cold cache this step both compiles the test-profile binaries (including the GTK/WebKit tree) and runs harness, upstream, four local-api invocations, and deco single-threaded with CARGO_BUILD_JOBS: 2 capping parallelism. Your own comments in this job say a cold run measured 25-35 min and was killed at ~30 — right at this cap. Since rust-cache saves in a post step, a step that times out at 25 min never warms the cache, which recreates exactly the 'every run starts cold' spiral this refactor is meant to eliminate. Consider raising the step timeout (or dropping the step-level cap and relying on the 60-min job timeout), especially for the first run after a cache eviction.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/native.yml, line 305:

<comment>The `cargo test (Linux)` step carries `timeout-minutes: 25`, but on a cold cache this step both compiles the test-profile binaries (including the GTK/WebKit tree) and runs harness, upstream, four local-api invocations, and deco single-threaded with `CARGO_BUILD_JOBS: 2` capping parallelism. Your own comments in this job say a cold run measured 25-35 min and was killed at ~30 — right at this cap. Since `rust-cache` saves in a post step, a step that times out at 25 min never warms the cache, which recreates exactly the 'every run starts cold' spiral this refactor is meant to eliminate. Consider raising the step timeout (or dropping the step-level cap and relying on the 60-min job timeout), especially for the first run after a cache eviction.</comment>

<file context>
@@ -196,13 +272,56 @@ jobs:
+      - name: cargo test (Linux)
+        if: runner.os == 'Linux' && matrix.task != 'lint'
+        working-directory: apps/native
+        timeout-minutes: 25
+        env:
+          CARGO_BUILD_JOBS: "2"
</file context>

Suggested change

	timeout-minutes: 25
	timeout-minutes: 50

[cubic-dev-ai]

7 issues found across 37 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="apps/native/crates/local-api/src/process_group.rs">

<violation number="1" location="apps/native/crates/local-api/src/process_group.rs:681">
P2: This skips the cleanup regression test on every Linux environment, including the real Linux kernel/container validation described above, so Ubuntu CI cannot catch regressions in this process-group behavior. The skip needs to be gated on the GitHub-runner condition at runtime (or the attribute should be removed), rather than on `target_os = "linux"`.</violation>
</file>

<file name=".github/workflows/native.yml">

<violation number="1" location=".github/workflows/native.yml:180">
P2: The two ubuntu-22.04 legs of `rust-checks-os` share the exact same `Swatinem/rust-cache` key (same runner OS, same Cargo.lock, same workspace), so GitHub's cache API will only let one of them persist its target dir each run; the second leg's save is silently dropped. That undercuts the goal the surrounding comments describe (each leg warming its own cache to break the cold-build spiral) — one Linux leg is likely to stay cold on disk every run and risk the same slow GTK/WebKit rebuild. Consider giving each task a distinct cache key (e.g. a `key` suffix based on `matrix.task` so lint and test caches are saved separately).</violation>

<violation number="2" location=".github/workflows/native.yml:802">
P1: A failure in `changes` can currently be reported as a passing required check: its dependent matrix is skipped, and this branch explicitly treats `skipped` as success without checking `needs.changes.result`. The aggregators would be safer if they first required `needs.changes.result == 'success'`, then allowed a skipped matrix only for the intentional irrelevant-path case; apply that guard to all three aggregators.</violation>
</file>

<file name="apps/native/crates/local-api/src/routes/git.rs">

<violation number="1" location="apps/native/crates/local-api/src/routes/git.rs:2238">
P2: A broken or unavailable `pgrep` makes this test pass without proving process cleanup because all enumeration failures are interpreted as an empty group. Propagating spawn errors and accepting only exit 1 as the empty-group result would keep the assertion fail-closed.</violation>

<violation number="2" location="apps/native/crates/local-api/src/routes/git.rs:2266">
P3: When cleanup is delayed, this loop can create substantial process and CPU churn for 15 seconds, worsening the CI failure it is trying to diagnose. A short timed sleep between probes would bound the polling rate.</violation>

<violation number="3" location="apps/native/crates/local-api/src/routes/git.rs:2266">
P2: This assertion normally checks a nonexistent process group and can pass even when the watchdog or Git descendant is still alive. The fixture needs to record/use the actual PGID, such as the shell's `ps`-reported PGID or a test hook exposing the anchored `child.id()`.</violation>
</file>

<file name="apps/native/crates/local-api/src/setup/dev.rs">

<violation number="1" location="apps/native/crates/local-api/src/setup/dev.rs:1012">
P2: Both process-group tests are ignored on every Linux build, not only GitHub-hosted runners, because `target_os = "linux"` is a compile-time target predicate. This removes Linux coverage for the identity and reaping behavior introduced here; a CI-specific skip mechanism would avoid disabling the tests for all Linux environments.</violation>
</file>

<sub>Tip: cubic can generate docs of your entire codebase and keep them up to date. Try it here.

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: A failure in changes can currently be reported as a passing required check: its dependent matrix is skipped, and this branch explicitly treats skipped as success without checking needs.changes.result. The aggregators would be safer if they first required needs.changes.result == 'success', then allowed a skipped matrix only for the intentional irrelevant-path case; apply that guard to all three aggregators.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/native.yml, line 802:

<comment>A failure in `changes` can currently be reported as a passing required check: its dependent matrix is skipped, and this branch explicitly treats `skipped` as success without checking `needs.changes.result`. The aggregators would be safer if they first required `needs.changes.result == 'success'`, then allowed a skipped matrix only for the intentional irrelevant-path case; apply that guard to all three aggregators.</comment>

<file context>
@@ -561,3 +785,54 @@ jobs:
+      - name: Verify rust-checks legs
+        run: |
+          case "${{ needs.rust-checks-os.result }}" in
+            success|skipped) echo "rust-checks: ${{ needs.rust-checks-os.result }}"; exit 0 ;;
+            *) echo "rust-checks: ${{ needs.rust-checks-os.result }}"; exit 1 ;;
+          esac
</file context>

[cubic-dev-ai]

P2: This skips the cleanup regression test on every Linux environment, including the real Linux kernel/container validation described above, so Ubuntu CI cannot catch regressions in this process-group behavior. The skip needs to be gated on the GitHub-runner condition at runtime (or the attribute should be removed), rather than on target_os = "linux".

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/local-api/src/process_group.rs, line 681:

<comment>This skips the cleanup regression test on every Linux environment, including the real Linux kernel/container validation described above, so Ubuntu CI cannot catch regressions in this process-group behavior. The skip needs to be gated on the GitHub-runner condition at runtime (or the attribute should be removed), rather than on `target_os = "linux"`.</comment>

<file context>
@@ -666,6 +666,19 @@ mod tests {
+    ///
+    /// The behaviour under test is confirmed working on Linux; this is a CI
+    /// exclusion, not a port gap.
+    #[cfg_attr(target_os = "linux", ignore)]
     #[cfg(unix)]
     #[tokio::test]
</file context>

[cubic-dev-ai]

P2: A broken or unavailable pgrep makes this test pass without proving process cleanup because all enumeration failures are interpreted as an empty group. Propagating spawn errors and accepting only exit 1 as the empty-group result would keep the assertion fail-closed.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/local-api/src/routes/git.rs, line 2238:

<comment>A broken or unavailable `pgrep` makes this test pass without proving process cleanup because all enumeration failures are interpreted as an empty group. Propagating spawn errors and accepting only exit 1 as the empty-group result would keep the assertion fail-closed.</comment>

<file context>
@@ -2225,6 +2225,19 @@ mod tests {
+            .stdout(std::process::Stdio::null())
+            .stderr(std::process::Stdio::null())
+            .status()
+            .is_ok_and(|status| status.success())
+    }
+
</file context>

Suggested change

	.is_ok_and(|status| status.success())
	.map(|status| match status.code() {
	Some(0) => true,
	Some(1) => false,
	code => panic!("pgrep failed with status {code:?}"),
	})
	.unwrap_or_else(|error| panic!("pgrep failed to execute: {error}"))

[cubic-dev-ai]

P2: This assertion normally checks a nonexistent process group and can pass even when the watchdog or Git descendant is still alive. The fixture needs to record/use the actual PGID, such as the shell's ps-reported PGID or a test hook exposing the anchored child.id().

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/local-api/src/routes/git.rs, line 2266:

<comment>This assertion normally checks a nonexistent process group and can pass even when the watchdog or Git descendant is still alive. The fixture needs to record/use the actual PGID, such as the shell's `ps`-reported PGID or a test hook exposing the anchored `child.id()`.</comment>

<file context>
@@ -2236,10 +2249,21 @@ mod tests {
-        tokio::time::timeout(Duration::from_secs(1), async {
-            while process_exists(format!("-{pid}")) {
+        tokio::time::timeout(Duration::from_secs(15), async {
+            while process_group_exists(pid) {
                 tokio::task::yield_now().await;
             }
</file context>

[cubic-dev-ai]

P2: Both process-group tests are ignored on every Linux build, not only GitHub-hosted runners, because target_os = "linux" is a compile-time target predicate. This removes Linux coverage for the identity and reaping behavior introduced here; a CI-specific skip mechanism would avoid disabling the tests for all Linux environments.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/local-api/src/setup/dev.rs, line 1012:

<comment>Both process-group tests are ignored on every Linux build, not only GitHub-hosted runners, because `target_os = "linux"` is a compile-time target predicate. This removes Linux coverage for the identity and reaping behavior introduced here; a CI-specific skip mechanism would avoid disabling the tests for all Linux environments.</comment>

<file context>
@@ -956,6 +995,21 @@ mod tests {
+    /// So this is a CI-environment exclusion, NOT a gap in the Linux port:
+    /// the behaviour under test is confirmed working on Linux. Re-enable by
+    /// making the runner reap orphans, or by having the anchor skip zombies.
+    #[cfg_attr(target_os = "linux", ignore)]
     #[cfg(unix)]
     #[tokio::test]
</file context>

[cubic-dev-ai]

P2: The two ubuntu-22.04 legs of rust-checks-os share the exact same Swatinem/rust-cache key (same runner OS, same Cargo.lock, same workspace), so GitHub's cache API will only let one of them persist its target dir each run; the second leg's save is silently dropped. That undercuts the goal the surrounding comments describe (each leg warming its own cache to break the cold-build spiral) — one Linux leg is likely to stay cold on disk every run and risk the same slow GTK/WebKit rebuild. Consider giving each task a distinct cache key (e.g. a key suffix based on matrix.task so lint and test caches are saved separately).

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/native.yml, line 180:

<comment>The two ubuntu-22.04 legs of `rust-checks-os` share the exact same `Swatinem/rust-cache` key (same runner OS, same Cargo.lock, same workspace), so GitHub's cache API will only let one of them persist its target dir each run; the second leg's save is silently dropped. That undercuts the goal the surrounding comments describe (each leg warming its own cache to break the cold-build spiral) — one Linux leg is likely to stay cold on disk every run and risk the same slow GTK/WebKit rebuild. Consider giving each task a distinct cache key (e.g. a `key` suffix based on `matrix.task` so lint and test caches are saved separately).</comment>

<file context>
@@ -140,19 +140,52 @@ jobs:
+          - os: macos-latest
+            task: all
+          - os: ubuntu-22.04
+            task: lint
+          - os: ubuntu-22.04
+            task: test
</file context>

[cubic-dev-ai]

P3: When cleanup is delayed, this loop can create substantial process and CPU churn for 15 seconds, worsening the CI failure it is trying to diagnose. A short timed sleep between probes would bound the polling rate.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/local-api/src/routes/git.rs, line 2266:

<comment>When cleanup is delayed, this loop can create substantial process and CPU churn for 15 seconds, worsening the CI failure it is trying to diagnose. A short timed sleep between probes would bound the polling rate.</comment>

<file context>
@@ -2236,10 +2249,21 @@ mod tests {
-        tokio::time::timeout(Duration::from_secs(1), async {
-            while process_exists(format!("-{pid}")) {
+        tokio::time::timeout(Duration::from_secs(15), async {
+            while process_group_exists(pid) {
                 tokio::task::yield_now().await;
             }
</file context>

Suggested change

	while process_group_exists(pid) {
	while process_group_exists(pid) {
	tokio::time::sleep(Duration::from_millis(20)).await;