Track agent-browser + vibium as managed components — visibility, not a fix request

[lafinak]

Track agent-browser (and vibium) as managed components — visibility, not a fix request

TL;DR

ak doesn't know about the Chrome-for-Testing binaries that agent-browser and vibium
download and cache, even though it already tracks equivalent caches for Playwright and
Puppeteer. This isn't a request to fix anything — both tools are standalone (not
components of ruflo), so per your own framing below, this is squarely an "include it so
it's under management and reporting" ask. Real numbers and a real ak system --deep run
included below, not hypotheticals.

Also surfaced along the way: ruflo itself already has a design (ADR-122, Proposed
2026-05-18) to ship exactly this kind of agent-browser health-reporting via
ruflo doctor — it just hasn't landed yet, four months later. Worth knowing about before
deciding where this should live.

Your framing (quoting you back, so we're aligned)

Keep me honest why don't you log a GitHub issue in my repo... I would like a little bit
more detail like please explain what it is that you're looking for.

I don't necessarily fix problems. I report them upstream. And then when things are
working, I include them.

If this is just about including the component so it's under management and reporting on
its health, I think I can do that.

If it's a component of ruflo then we have to wait for it to have a fix. If it's
something that stands on its own, maybe there's something we can do.

Both tools involved here stand on their own — confirmed by reading each package's own
package.json:

Tool	Owner	Repo
agent-browser	Vercel Labs	github.com/vercel-labs/agent-browser
vibium	VibiumDev	github.com/VibiumDev/vibium — vibium.com

Neither is a ruflo component. Per your own rule, this is the "maybe there's something we
can do" case, not the "wait for ruflo to fix" case.

How this started (the actual bug, already filed elsewhere)

While using ruflo-browser's MCP tools (mcp__ruflo__browser_* — the 23-tool plugin,
more on that below) for real browser automation, agent-browser's own Chrome-for-Testing
download (~194MB) reliably failed at ~95%, 3 retries, same point every time, silently
exiting 0 despite failing. Root-caused this properly (not guessed):

• A plain curl to the exact same URL completed cleanly in 124s at ~1.56MB/s.
• agent-browser's own binary embeds AGENT_BROWSER_DEFAULT_TIMEOUT /
  AGENT_BROWSER_IDLE_TIMEOUT_MS env knobs (confirmed via strings on the Rust binary —
  it's reqwest + tokio::time::timeout).
• Initially attributed the failure to a too-tight fixed timeout. Later corrected: after
  fixing an unrelated full network outage in the same sandbox (a container restart was
  required — DNS resolved fine, but every outbound TCP connection was timing out), re-ran
  the exact same agent-browser install with no override and it succeeded cleanly, 100%,
  1m42s, no retries. So the real explanation is more likely a transient network
  degradation at the time of the original failures, not a permanently-too-tight timeout.

Filed with full detail, later corrected in a follow-up comment once the network issue was
understood: ciprianmelian/ruflo-aqe-kit#21
(ciprianmelian/ruflo-aqe-kit#21). That's the right home for the
bug itself — this issue here is only about ak visibility, not about re-litigating the
bug.

The concrete gap, with real numbers from this machine

Workaround while debugging: agent-browser was pointed at an already-downloaded,
same-version Chrome binary that a completely unrelated tool (vibium, via a
qe-browser skill) had cached — ~/.cache/vibium/chrome-for-testing/152.0.7977.64/.
Once the network issue was separately fixed, agent-browser also completed its own real
download successfully — so this machine now has two full, duplicate Chrome-for-Testing
152.0.7977.64 installs:

413M  ~/.cache/vibium/chrome-for-testing/152.0.7977.64
391M  ~/.agent-browser/browsers/chrome-152.0.7977.64

~800MB of duplicate binary. Ran ak system --deep on this exact machine to check whether
ak already sees this — full, real, unedited output:

Storage  — measured 2026-09-01 02:16
  total           934 MB · 4,028 files

  CATEGORY          SIZE     FILES
  learning-stores   886 MB   3,826
  transcripts       45.2 MB  95
  kit-caches        1.85 MB  49
  ledgers-and-logs  1.23 MB  58

  reclaimable (advisory only — ak system removes nothing)
  CANDIDATE                                            SIZE     CLEANUP
  npm content-addressable cache                        1.65 GB  npm cache clean --force
  orphaned worktree record "pre-gastown-ruflo-repair"  0 B      git worktree prune

Four storage categories, two reclaimable candidates. Zero mention of either Chrome cache,
anywhere. ak system's Install table already tracks ruflo, agentic-qe, Claude Code,
OpenCode, and RuvNet Brain (version / install method / size) — this is asking for
agent-browser and vibium to join that same table, using the same shape you already
have.

What I'm actually asking for

Two things, both purely additive to the existing ak system model:

1. Install-table entry for agent-browser (and vibium, since it's already a
   dependency this stack pulls in via the qe-browser skill) — version, size, install
   method, same columns as the existing rows.
2. A health signal, not just presence. agent-browser doctor already reports whether
   it has a working Chrome binary:

   Chrome
     fail  No Chrome binary found
     pass  Chrome for Testing CDN reachable (280ms, HTTP 200)
     fail  Browser launch failed: Chrome not found. Checked: ...
   

   Surfacing that signal in ak system would have caught the original problem in feat(providers): detect + configure claude/codex hosts and LLM providers #21
   immediately — instead of requiring a manual filesystem investigation across multiple
   cache directories to even discover a working binary existed.

Not asking for a fix to the download bug itself — that's Vercel Labs' code, outside your
control or ciprianmelian's, and it's already filed at the right place.

One more thing worth knowing before deciding where this lives

While digging into ruflo-browser, found ruflo/v3/docs/adr/ADR-122-browser-beyond-sota.md
(Status: Proposed, dated 2026-05-18, still Proposed as of today — ruflo doctor
still says nothing about agent-browser, confirmed by actually running it). It documents
that ruflo has two separate, drifting browser systems internally:

	@claude-flow/browser (v3 monorepo, 59 MCP tools)	ruflo-browser plugin (23 MCP tools)
agent-browser dependency	locked to ^0.6.0, upstream was at 0.27.0 (21 versions behind) at ADR write time	shells out to whatever's on PATH
What's actually running in this project	not this one	confirmed this one, by counting the live registered mcp__ruflo__browser_* tools (exactly 23)

ADR-122's own Phase 0 (its "highest-yield, lowest-risk" first step) is specifically:
bump the locked agent-browser version, converge the two systems, and — this is the
relevant part — "ruflo doctor reports agent-browser version and warns when below
0.27." That's the same health-reporting capability being asked for here, just scoped to
land inside ruflo itself instead of ak.

So there's a real design that already intends to close this gap — it's just stalled
(Proposed since May, not shipped by September). Flagging this so the decision is informed:
ak including agent-browser/vibium now is still valuable regardless of whether/when
ADR-122 ships (health-checking a third-party binary a project depends on is ak's job
either way) — but it's bridging a known gap rather than inventing new scope from nothing.

Three more gaps, found the same session, all verified against your source

Not padding — these came up solving the actual problem above and are all confirmed
against the installed 4.0.0-alpha.44 source, not guessed. Splitting them out so they
don't dilute the main ask, but flagging them since you asked for detail and they're the
same shape of "ak already has 90% of this, just missing a piece."

1. ak x mcp pick's legacy-key migration is blind to project-scoped registrations

src/lib/mcp.mjs's registrationStatus() / register() only read/write
~/.claude.json's top-level mcpServers (claudeUserMcpPath() →
path.join(home, '.claude.json'), global scope). This project's actual live MCP
registration — the one every mcp__ruflo__browser_* call in this whole investigation
went through — lives at ~/.claude.json → projects["/workspaces/turbo-flow-wsl"] .mcpServers.ruflo, plus a project-local .mcp.json. Neither is visible to
registrationStatus()'s legacyRuflo check or x mcp pick's migration.

Concretely: this machine's global scope is already clean (claude-flow registered,
no legacy ruflo key) — but this project's own registration is still on the legacy
ruflo key, entirely invisible to the tooling that's supposed to catch that. Confirmed
by reading ~/.claude.json directly: the project-scoped entry existed with env: {},
silently shadowing every env var the project's own .mcp.json declared — which is what
actually broke the fix for the Chrome-binary path above and needed manual patching
across both files.

2. ak x daemon-gc doesn't cover orphaned ruflo mcp start processes

x/daemon-gc.mjs + lib/daemons.mjs already do exactly the right thing — TTL-based
staleness, workspace-gone detection, list-by-default/--kill-to-reap — for ak's own
background daemons. Zero references to mcp start process discovery anywhere in
daemons.mjs. Also worth a look while you're in there: a separate bead from this same
project's internal tracker found a stray ruflo daemon start --foreground --workspace <unrelated-nested-path> process, and daemon-gc's own "1-per-project is normal"
heuristic considered it healthy and left it running — it doesn't currently catch a
daemon that's alive and within its TTL, but pointed at the wrong project. Meanwhile, watched /mcp reconnect (in Claude Code, not ak) spawn a new
ruflo mcp start process pair on every reconnect without killing the one it replaced —
confirmed live: 3 separate spawns in one terminal within 6 minutes, all still running
(kill -0 succeeded on each) after later ones had superseded them. Already reported the
underlying leak as Claude Code product feedback (not ak's or ruflo's bug), but
daemon-gc's existing pattern would be the natural place to also let people clean up the
resulting mess, the same way it already does for ak's own daemons.

3. ak's own ALLOW_SCRIPTS allowlist is missing @anthropic-ai/claude-code

This one's the most concrete — it's the literal cause of a "claude native binary not
installed" failure hit and hand-fixed this same session. lib/heal.mjs has:

// Packages whose install scripts must run for natives to build (npm >=11.17
// blocks them by default). Curated on the live 3.28/3.12.2 upgrade.
const ALLOW_SCRIPTS = [
  'ruflo', 'agentic-qe', '@claude-flow/cli', 'better-sqlite3', 'hnswlib-node',
  'agentdb', 'agentic-flow', 'argon2', 'onnxruntime-node', 'sharp', 'protobufjs',
  '@google/genai', 'tldjs', 'vibium',
].join(',');

@anthropic-ai/claude-code isn't in it. Its postinstall (install.cjs) is exactly the
kind of native-binary-fetching script npm ≥11.17 blocks by default — same failure mode
ALLOW_SCRIPTS already exists to prevent for 14 other packages. Hit this directly: an
auto-update bumped the wrapper package but the postinstall that fetches/links the
matching native binary got silently blocked, and dsp/claude broke with "native binary
not installed" until fixed by hand (adding @anthropic-ai/claude-code to
~/.npmrc's allow-scripts). Since ak is what most people would reach for to heal a
broken Claude Code CLI install, and it already has the exact mechanism to prevent this
one specific package from ever hitting it — seems like a one-line fix with real, verified
impact.

This isn't a one-off, either — this project's own internal tracker shows the same class
of break recurring over weeks. One earlier incident hit and fixed the exact same
mechanism as this session — a fresh npm install -g blocked by the allow-scripts policy
— with the identical fix, about two weeks before this session independently
rediscovered it from scratch. That's the confirmed, reproducible failure mode
ALLOW_SCRIPTS would directly prevent.

A separate, earlier incident found something related but not fully
explained: 3 breaks in one session where the claude.exe wrapper got reset to a bare
failure stub while the actual ~330MB native binary stayed completely intact — not
obviously a full reinstall each time. Its author ruled out cron, systemd, shell hooks,
.bashrc/aliases, and devcontainer lifecycle scripts, killed a stray unrelated daemon as
a leading suspect (didn't help), and gave up identifying the real trigger, landing on a
.bashrc self-heal workaround instead — so it's honest to say ALLOW_SCRIPTS is
confirmed to fix the ltpp/this-session pattern, not necessarily gdrr's deeper mystery.
Still worth including as evidence this general area (Claude Code's native binary going
missing) has cost real time here more than once.

References

• Bug report (already filed, with a correction comment): agent-browser Chrome-for-Testing download times out at ~95% — fixed total-duration timeout, not a network failure (browser_act, ADR-175) ciprianmelian/ruflo-aqe-kit#21
• ADR: ruflo/v3/docs/adr/ADR-122-browser-beyond-sota.md
• Security audit for the newer system: ruflo/v3/@claude-flow/browser/docs/SECURITY_AUDIT.md
• Gist that prompted this dig: https://gist.github.com/ruvnet/a708fafb1375ed69bc48377df47fa2ac

[pacphi]

Independent verification is complete. The changes below are implemented in a worktree based on the then-current origin/main; they are not yet committed, pushed, or released.

Fixed in agentic-kit

• Browser visibility: ak system and the Dashboard now report agent-browser and Vibium install presence/version, dependency owner, cache path/bytes, payload readiness, and revision. These are deliberately observed dependency-owned runtimes, not agentic-kit-managed packages: Ruflo owns the agent-browser integration and Agentic QE owns Vibium.
• Browser health boundary: readiness is filesystem-derived and read-only. agent-browser requires a recognized cached Chrome executable; Vibium requires Chrome and chromedriver in the same revision. System does not launch a browser, download anything, or call a third-party doctor whose current path has side effects.
• Claude MCP scopes: status now inspects local, project, and user registrations with local > project > user precedence. Only the legacy user-scoped ruflo key is automatically migratable; local/project entries are reported and preserved.
• MCP orphan visibility/cleanup: ak x daemon-gc now inventories Ruflo MCP stdio transports. Cleanup requires explicit --mcp --kill, same-user ownership, PPID 1, an exact Ruflo MCP command shape, and an immediate unchanged-identity recheck before SIGTERM. Age, count, and workspace guesses never authorize a kill.
• npm lifecycle handling: every agentic-kit-owned global npm install now uses one reviewed lifecycle allowlist, including @anthropic-ai/claude-code and opencode-ai. Initial host installation also requires <host> --version to succeed; npm exit 0 alone is no longer reported as a usable host.
• Future skill projection containment: published Ruflo 3.38.21 ignores --no-codex-detect and --no-skills-sh. Agentic-kit now additionally uses scripted JSON mode plus RUFLO_NO_SKILLS_SH=1, which was proven in a fresh directory to suppress the optional Codex/skills.sh projections.

Verified but not changed

• Original agent-browser download timeout: dismissed here. The reporter corrected it as a transient network outage, and the same download later succeeded without a timeout override.
• agent-browser doctor integration: not added. Its current path can remove stale daemon sidecars, which violates the read-only System contract. The filesystem readiness signal supplies bounded visibility without importing that side effect.
• Browser-cache deduplication/deletion: not added. The caches have different upstream owners and may serve pinned consumers. They are visible and reviewable; agentic-kit does not infer deletion safety.
• “Wrong project” daemon cleanup: not added. A live, parented daemon is not safely killable from workspace disagreement alone.
• Memory hooks/store: no repair was warranted. Native .swarm/agentdb-memory.db and compatibility .swarm/memory.db behavior verified as designed, and ak x verify memory passed.
• Codex Stop-hook output: agentic-kit already detects the signed Ruflo 3.38.21 shape. This remains an upstream defect; no generated/cache file was patched downstream.

Skill/MCP context-budget finding

• The Codex warning is real skill-catalog pressure. On this machine the project contributes 243 skills, enabled plugins contribute 33 in a separate Codex prompt-input census, and user/system roots contribute the remainder. That census listed 285 entries; the active App warning omitted 80, so the two Codex surfaces are not assumed byte-identical.
• This is primarily multi-channel accumulation and semantic overlap, not literal duplicate files: the 243 project skills have no duplicate names or identical bodies; only one exact cross-channel basename overlap was found (skill-creator). Large families (agent-*, source-command-*, QE/testing, v3) still overlap in purpose.
• There is no separate claude-flow Codex MCP registration alongside ruflo; those are not two independently installed engines on this machine. Across the seven visible MCP namespaces, 16 operation names overlap, but inspection showed different domain/store semantics. The warning shown is about skills, not MCP schemas; exact MCP schema-token cost is not recorded and was not fabricated.
• Existing project skills were not auto-deleted. They predate usable ownership receipts, and familiar names do not prove who wrote or edited them. Safe upgrade cleanup requires an exact path + last-written digest receipt and unchanged bytes. Ruflo #3153 supports that migration rule for known generated skill revisions; it does not justify a blanket purge.

Upstream disposition

New evidence-bound reports filed:

• ADR-122 Phase 0 is marked shipped but ruflo doctor never reports agent-browser ruvnet/ruflo#3166 — ADR-122 says browser doctor visibility shipped, but released doctor does not report agent-browser.
• aqe init Vibium preflight can install twice and reports CLI presence as browser readiness proffesor-for-testing/agentic-qe#656 — Vibium preflight can install twice and conflates CLI presence with browser-payload readiness.
• ruflo init 3.38.21 ignores --no-codex-detect and --no-skills-sh ruvnet/ruflo#3167 — 3.38.21 ignores --no-codex-detect and --no-skills-sh.

No duplicates were filed where an upstream issue already exists: Ruflo MCP orphan leak #2234, Stop-hook output #3163, npm/browser postinstall #2639, init/plugin duplication #2640, generated instruction/skill migration #3153, AQE Vibium version mismatch #561, and Codex skill-budget warning openai/codex#19679. The issue author has already added the current Codex warning evidence to #19679.

Verification

• Focused changed-area tests: 100/100 passed; status/process tests: 62/62 passed.
• Full pnpm test: passed with 89.43% aggregate line coverage.
• Dashboard UI: 382/382 passed.
• Typecheck, build, Markdown lint, diff check: passed. ESLint: zero errors; 45 existing repository warnings.
• Live deep scan proved the new rows: agent-browser absent/Ruflo-owned; Vibium installed/Agentic-QE-owned and payload-ready at 148.0.7778.56, with a 744,217,479-byte cache.

I will link the implementation commit/PR here once one is authorized and available.

[pacphi]

Final implementation addendum — supersedes the earlier provisional disposition

PR #199 implements the independently verified work at 128f178. This comment supersedes my earlier comment above, especially its provisional description of agent-browser as “observed-only”: agentic-kit now manages the Ruflo-compatible agent-browser package and its Ruflo-scoped configuration. Vibium remains observed and Agentic-QE-owned.

Fixed in agentic-kit

• Managed Ruflo browser executor: install the exact Node-compatible release (0.27.0 on Node 22/23, 0.27.3 on Node 24+), verify the package-owned native CLI and version, bind the package root/executable/SHA-256 to an ownership receipt, and refuse drifted or user-owned state. Only managed Ruflo MCP children receive the trusted headless config. Uninstall preserves browser payloads, sessions, profiles, and cookies.
• Browser component visibility: status, About, ak system, and the dashboard distinguish managed agent-browser from AQE-owned Vibium and report version, update owner, cache bytes/path, payload readiness, and revision.
• npm lifecycle hooks: every agentic-kit-owned global install now shares one reviewed install-script policy, including @anthropic-ai/claude-code, opencode-ai, and agent-browser. Host installation must also pass <cli> --version; npm exit 0 is no longer enough.
• Claude MCP scopes and migration: local, project, and user registrations are inventoried with their actual precedence. Automatic migration is limited to a recognized canonical user registration; conflicting or scoped user-owned entries are preserved, and failed replacement rolls back.
• Orphaned Ruflo MCP cleanup: ak x daemon-gc inventories transports, but only explicit --mcp --kill may reap a same-user, PPID-1, exact-command process whose identity is unchanged on immediate recheck.
• Ruflo projection containment: because released Ruflo 3.38.21 ignores its documented Codex/skills suppression flags, setup adds JSON/script-mode containment so future clean installs do not project those optional trees.
• Project skill inventory and clean-room harness: System now includes the launching repository plus observed historical projects and their Codex .agents/skills; Docker can run repeatable setup/sync passes and emit status/System evidence.

Dismissed or deliberately not implemented

• Original agent-browser timeout theory — dismissed: the reporter corrected it to a transient network outage, and the unmodified download later succeeded.
• agent-browser doctor in System — not used: its current path may mutate stale sidecars, which violates the read-only System contract. Readiness is derived from bounded filesystem evidence.
• Automatic browser-cache deduplication — not done: agent-browser and Vibium have different owners and consumers; matching browser revisions do not establish deletion authority.
• Blanket removal of 243 project skills — not done: no duplicate names or identical bodies were found within that tree, and the files predate usable agentic-kit ownership receipts. Semantic overlap is not deletion authority.
• MCP removal based on overlapping tool names — not done: the displayed Codex warning is about skills, and MCP schema-token cost was not observed. Ruflo and AQE operations with similar names have different stores/domains.
• “Wrong project” daemon kill heuristic — not done: workspace disagreement alone is insufficient authority to kill a live parented process.
• Servo integration — deferred: current released Ruflo still selects the agent-browser-backed path. ADR-0043 provides a replaceable boundary for Servo when a released upstream artifact actually ships and selects it.
• Memory-hook repair — dismissed: native/compatibility AgentDB paths and ak x verify memory behaved as designed.

Skill-pressure conclusion and follow-up

The exact-head clean Docker install ran ak setup --codex --opencode --yes --no-ruvnet-brain and two ak sync --yes passes. It converged with 0 Codex skills and one Codex Ruflo MCP entry. This repository currently contributes 243 project-scoped Codex skills; the host has 394 deduplicated Codex skills across observed project, user, and plugin surfaces. Therefore current setup does not recreate the 243-file tree; it is historical residue.

Project-by-project source attribution, receipt classification, a dry-run remediation plan, and any later explicit plan-bound apply workflow are tracked in #198. That work preserves System as read-only and does not authorize deleting the current unreceipted tree.

Upstream disposition

New evidence-bound reports filed:

• ADR-122 Phase 0 is marked shipped but ruflo doctor never reports agent-browser ruvnet/ruflo#3166 — released doctor lacks the browser reporting described by upstream design;
• aqe init Vibium preflight can install twice and reports CLI presence as browser readiness proffesor-for-testing/agentic-qe#656 — Vibium preflight/install/readiness defects;
• ruflo init 3.38.21 ignores --no-codex-detect and --no-skills-sh ruvnet/ruflo#3167 — released init ignores documented Codex/skills suppression flags.

Existing reports were not duplicated: ruvnet/ruflo#2234, #2639, #2640, #3153, #3163; proffesor-for-testing/agentic-qe#561; openai/codex#19679; vercel-labs/agent-browser#1310, #1441, #1679; anthropics/claude-code#80021. Chrome for Testing’s missing Linux ARM64 distribution is already tracked upstream (GoogleChromeLabs/chrome-for-testing#1) and is explicit in agent-browser’s installer, so no duplicate was filed.

Final evidence

• PR fix: verify #189 and manage Ruflo browser executor #199 CI: green on Linux, macOS, and Windows with Node 22/24/26; quality/audit, internal links, dashboard UI, and the checkout-built maintainer devcontainer all passed.
• Local: full pnpm test, typecheck, build, Markdown lint, complexity ratchet, and focused browser/npm/MCP tests passed; dashboard UI 382/382.
• Exact-head Docker clean room: setup plus two sync passes converged with no failing subsystem; 118 Claude skills, 0 Codex skills, 0 OpenCode skills, and 3 total MCP identities.
• Linux ARM64: agent-browser CLI is managed and ready, while its Chrome payload is honestly degraded because Chrome for Testing publishes no Linux ARM64 build. No retry loop or fabricated fix is offered.

No merge or release was performed.

[pacphi]

Settlement update — setup/Codex MCP correction

PR #199 is now at 634426a, with the full CI matrix green. This supplements the prior final addendum and corrects the remaining out-of-box setup gap discovered while validating the dashboard on the maintainer host.

What the red MCP card actually was

• The host still had an unowned user-scope [mcp_servers.codex] entry running codex mcp-server.
• Current clean ak setup --codex does not create that registration; it was historical upgrade residue.
• Setup previously preserved it because agentic-kit had no ownership receipt and did not reconcile effective Codex config.toml. That was conservative, but it allowed setup to finish while the dashboard remained red.

Fixed

• ak setup --codex now inventories effective Codex MCP topology before mutation and includes every eligible repair in the setup trust manifest.
• Automatic removal is limited to exact known legacy shapes. Custom commands, extra fields, child tables, lookalikes, and symlinked configs remain visible/report-only.
• Every affected regular config gets a unique recovery copy containing the immediate pre-repair bytes.
• User-scope removal uses Codex's supported user-config command; project-scope removal uses a bounded exact-table edit, avoiding cross-scope deletion.
• The confirmed file/scope/name/command/args/body fingerprint is rechecked immediately before each removal, and absence is verified afterward.
• Machine-only/outside-project setup repairs only the recursive user Codex entry. It preserves legacy Ruflo until project convergence can install the canonical replacement.
• The maintainer host was repaired: recursive Codex is absent, one canonical workspace-aware Ruflo MCP remains, AQE MCP is registered, and ak status reports all relevant rows healthy.
• The About card now reports the managed agent-browser version (0.27.3) instead of only “installed”.

Still dismissed or deliberately not done

No prior disposition changed: no browser timeout workaround, no mutating agent-browser doctor call from System, no automatic cache deduplication, no blanket 243-skill deletion, no MCP removal based on overlapping operation names, no wrong-project daemon kill heuristic, and no Servo integration until a released Ruflo artifact actually selects it.

Final evidence

• focused setup/MCP/status/sync tests: 127/127;
• full npm test: passed;
• dashboard tests: 85/85; UI: 383/383;
• typecheck, build, Markdown lint, complexity ratchet: passed;
• ESLint: zero errors and no new warning from this repair;
• independent read-only safety review: no merge blockers;
• PR CI: green on Linux/macOS/Windows with Node 22/24/26, plus quality/audit, links, UI, and checkout-built maintainer devcontainer.

PR: #199. The separate project-by-project skill inventory/remediation plan remains tracked in #198.

[pacphi]

Closing — this was fully implemented and independently verified in PR #199 (merged as d4f638d), addressing agent-browser/Vibium managed tracking, browser executor receipts, MCP scope inventory/migration, and the npm lifecycle hardening described above. The fix has since shipped in the 4.0.0-alpha.46 release.

Reopen if any of the verified behavior above doesn't hold up in practice.