dev-mode + logging update

[nphias]

• upgraded holochain_client and dependencies (0.5 series)
• created a DEV-MODE with an md to explain how it works and what code was added - no interference with production path
• modified storage.json config and setup files to use dev-mode (optional boolean)
• revamped logging .. (see logging.rs under conductora/src) - easier to understand and use - documented in file
• updated root package.json with some common log options

[evomimic]

Overall Comment

Thanks for splitting this out as a separate PR. This is a nice addition. I definitely noticed the speed-up in re-runs, and the ability to control logging for app starts from the same WASM_LOG and RUST_LOG environment variables is really clean. I also appreciate the supporting documentation in logging.rs.

There are a few things I recommend before merge.

---

Issues To Address Before Merge

1. Activation Model

My main concern is the usability and misconfiguration risk of the current dev-mode activation model.

Right now, enabling or disabling dev mode appears to depend on config-level mode switching rather than a single explicit launch-time toggle. That creates a few problems:

• enabling/disabling dev mode is more cumbersome than it needs to be
• it is easier than it should be to end up in the wrong mode unintentionally
• checked-in config can accidentally bias everyone toward the dev path
• the docs have to explain too many mode-switching details because the feature is not activated in a single obvious way
• users may have to reason about multiple config choices (default_storage, provider selection, dev_mode, signal URL behavior, etc.) just to understand what mode they are actually running in

For a feature that is explicitly developer-focused and intentionally non-production-like, I think that is the wrong usability model.

Recommendation

I recommend making an environment variable such as HC_DEV_MODE=1 the sole determinant of whether the app runs in dev mode.

That would make the feature:

• explicit
• session-scoped
• much harder to activate accidentally
• easier to explain
• easier to disable
• independent of checked-in config defaults

With that approach, the user-facing model becomes very simple:

• normal mode: run normally
• dev mode: launch with HC_DEV_MODE=1

Everything else — loopback signaling, disposable conductor state, DangerTestKeystore, cache-preserving wipe behavior, etc. — would remain automatic consequences of that one toggle.

That would also simplify the documentation substantially. Instead of explaining how to switch config into and out of dev mode, the docs could focus on:

1. how to enable it
2. how to disable it
3. what it changes internally

I think this would make the feature safer, clearer, and more aligned with the fact that dev mode is a temporary local-development behavior rather than a deployment mode that should live in checked-in runtime config.

---

2. Higher-Visibility Indication of Dev Mode

Even if activation is made explicit, I think dev mode should also be unmistakable when it is active.

At minimum, I would recommend a loud startup log line such as:

HOLOCHAIN DEV MODE ENABLED: ephemeral keystore, local signaling, disposable conductor state

Since dev mode changes persistence, identity, and restart behavior in important ways, it should be difficult to miss once the app is running.

---

3. Single Hard-Coded Conductor Path

host/conductora/plugins/tauri-plugin-holochain/holochain_runtime/src/launch/config.rs and host/conductora/plugins/tauri-plugin-holochain/holochain_runtime/src/launch.rs

As implemented, this is a machine-global path outside the repo, so all dev-mode runs on the same machine share one conductor state/cache regardless of repo clone, branch, app ID, or configured provider name. That creates an isolation problem: if I have multiple clones of the repo, multiple branches with different happ/code state, or multiple configured dev providers, they can all end up wiping and reusing the same dev conductor directory. In practice that means one dev instance can interfere with another, startup behavior becomes order-dependent, and the “fast warm start” cache can come from the wrong workspace/context.

These scenarios may not be common, but if they do happen they will likely be difficult to diagnose.

I think the fix here is straightforward: keep the idea of a stable dev conductor directory, but derive it from some combination of stable context such as app ID, provider name, and/or workspace identity, rather than using one global /tmp/conductora_dev path for everything. For example, a path shaped more like /tmp/conductora_dev/<app_id> or /tmp/conductora_dev/<provider_name>-<app_id> would be much safer. The important part is that the same derivation helper should be used consistently for both conductor config generation and cleanup.

---

4. Dev Mode as Default

host/conductora/src/config/storage.json

As currently implemented, the checked-in config selects the dev-mode path by default. That is a problem because it changes the app’s out-of-the-box behavior for everyone and increases the chance of running in dev mode unintentionally.

I think this concern largely disappears if dev mode is moved behind a dedicated launch-time switch such as HC_DEV_MODE=1, rather than being selected through checked-in runtime config.

If the current config-driven activation model is kept, then default_storage should remain on the normal production-like path and dev mode should stay explicitly opt-in.

---

5. Start Scripts Are Not Building the Happ

package.json

start:info and start:info:all should rebuild the happ, just like start and start:debug*. Right now those commands can run against stale or missing guest artifacts after a clean tree or guest changes. If a faster host-only path is useful, I’d suggest adding separate explicitly named scripts for that rather than changing the behavior of the existing start:* commands.

---

6. Dev Mode Runtime Behavior

host/conductora/src/config/storage.json

The dev signal URL behavior should be clarified. If runtime dev mode always overrides the configured signal_url with loopback signaling, I’d either remove the misleading config value or document clearly that it is ignored in dev mode. If it is not always overridden, then the current 0.0.0.0 value looks wrong as a client target and should be replaced with something valid.

Recommendation

If the items above are addressed, I think this PR would be merge-ready and a net improvement to the developer experience.

[evomimic]

Re-Review Implementation of HC_DEV_MODE Approach (after Commit e9a673d)

1. Remove env variables from start scripts

We learned the hard way from our sweetest scripts that environment variables are not always conveyed reliably across nested script/shell boundaries. Ultimately, we found it simpler and more reliable to stop encoding mode control through layered script chaining and rely on explicit exported env in the calling shell.

The latest commit included a number package.json scripts that tried to set environment variables on start (e.g, start:warn, start:info, start:fast).

Fix Applied:

I updated the package.json as follows:

• remove the extra mode-specific start scripts (start:fast, start:info, start:warn, start:debug, etc.)
• keep a single start script with pass-through defaults:
  • RUST_LOG=${RUST_LOG:-host:warn}
  • WASM_LOG=${WASM_LOG:-warn}
  • HC_DEV_MODE=${HC_DEV_MODE:-0}
• enable dev mode explicitly via shell/session (export HC_DEV_MODE=1) when desired

This restores a safe default, keeps mode activation explicit, reduces script complexity, and aligns runtime behavior with documentation.

2. Eliminate default_storage from storage.json

The PR originally still relied on a default storage selection in storage.json, which conflicted with the goal of making startup mode fully driven by HC_DEV_MODE.

What we changed

• Removed "default_storage": "holochain_dev" from storage.json.
• Kept both Holochain profiles in config (holochain_dev and holochain_production).
• Made HC_DEV_MODE the single source of truth for selecting the active profile at startup.

Selection behavior is now:

• HC_DEV_MODE=true -> select holochain_dev
• HC_DEV_MODE=false/unset -> select holochain_production

Implementation details

1. Kept both provider entries in config.
2. Moved profile selection into startup/config resolution logic (load_storage_config -> select_holochain_profile).
3. Eliminated dependency on default_storage for mode selection.
4. Added fail-fast validation with clear errors if required profiles are missing or mis-typed.

This removes ambiguity between config defaults and runtime mode, and keeps dev mode explicitly env-driven.

DEV_MODE.md file too hard to find

One remaining concern: DEV_MODE.md is buried under plugin internals and is unlikely to be discovered by most developers.

Fix Applied

I moved it to top-level directory.

Ready to Merge

After applying the above fixes:

• I confirmed build:happ and build:host complete just fine
• npm test -- all 11 tests pass
• npm start (with HC_DEV_MODE=1) -- app started quickly with strong WARNING
• npm start (with HC_DEV_MODE=) -- app started slower with no dev mode warning
• temporarily changed "holochain_production" to "holochain_production-bad" in storage.json and confirmed "fail-fast" behavior
• restored storage.json
• confirmed CI checks pass

Everything looks good.

PR Approved.