No way to see the environment, or the rendered command, a hook will run with

Summary

There is no way to ask what environment a hook will run with, or what a command
renders to, without running it. For a tool whose central value is "which
database does this command actually talk to", that question should be
answerable directly.

What happened

Integrating newgit into a monorepo where each instance gets its own Postgres,
I needed to know whether [restore] receives the allocated port in its
environment — because the restore command drops and rebuilds a schema, and the
wrong answer means dropping the developer's main database rather than the
instance's.

With no way to inspect it, I answered the question by planting a sentinel row
in the shared database and running a real newgit undo to see whether the row
survived. It did, so the answer was yes. (It is yes — see the assemble_env
call sites — but the docs do not say so, which is #77.)

That is a destructive experiment against live state to learn a static fact.

What would have answered it in one second

$ newgit env feature/x --resource db
CSR_PG_PORT=5434            # infra [ports.pg]
CSR_MQTT_PORT=1884          # infra [ports.mqtt]
CSR_NG_COMPOSE_PROJECT=csr-feature-x   # infra [exports]
NEWGIT_BRANCH=feature/x
NEWGIT_WORKSPACE=/Users/.../feature-x

assemble_env (crates/newgit-core/src/manager.rs:1634) already computes
exactly this and is already pub. Printing it is close to free, and naming the
resource each variable came from also surfaces the single-owner rule that
check_env_names enforces (resource.rs:1111).

The companion is a dry run:

$ newgit action infra.prepare feature/x --dry-run
would run in /Users/.../feature-x:
  CSR_NG_COMPOSE_PROJECT=csr-feature-x mise run db:up

which shows template substitution resolved — the thing you actually want to
check before letting a [cleanup] command with docker compose down -v in it
run for the first time.

Why this matters

The whole premise is that per-branch state is re-established by commands whose
targets come from newgit's environment. When that resolution is opaque, the
only way to validate a destructive hook is to fire it. --verify covers the
checkpoint/restore pair well; nothing covers "what is this command about to
be".

Adjacent: #8 ("Iterating on resource scripts requires committing every
attempt") is the same friction one step later — that one is about the edit
loop, this is about seeing the inputs at all.

Start with assemble_env in crates/newgit-core/src/manager.rs:1634 and check_env_names in resource.rs:1111 to understand the existing environment data and ownership rules. Trace the infra.prepare action entry point for the dry-run path. Done means the CLI can show resolved hook environment values and render a command without executing it.