feat(config): experimental worktrunk.config.* git-config project-config source

[indexzero]

What this adds

An experimental second source for project configuration: worktrunk.config.* keys in git config.

$ git config worktrunk.config.post-start 'pnpm install'
$ git config worktrunk.config.list.url 'http://localhost:3000'

One mechanical rule governs the mapping. Strip worktrunk.config.; the remainder is the exact key path from .config/wt.toml. worktrunk.config.post-start is the top-level post-start hook. worktrunk.config.list.url is [list] url. No renamed keys, no parallel schema.

Why

.git/config is never committed, never pushed, never cloned. Configuration written there is private to one machine by construction — and shared across every linked worktree, because the local scope lives in the common git dir. That combination is what issue 3454 asks for, and what several earlier issues (650, 1077, 2818) kept circling: private, repo-local config without a new file format and without repo identities leaking into public dotfiles.

How selection works

All-or-nothing. When any worktrunk.config.* key exists, those keys are the complete project config; .config/wt.toml is ignored. There is no key-level merging between sources.

Two consequences follow, both deliberate:

• Supersession is loud. When a project config file would otherwise load, a once-per-invocation warning names it, and a hint gives the diagnostic command: git config --show-scope --show-origin --get-regexp '^worktrunk\.config\.'. wt config show and wt hook show name the active source.
• Parse failures are fatal. An invalid value errors with the schema's own message. Falling back to the file would silently change which hooks run.

What stays the same

• Approval. Hooks and aliases from git config pass through the same approval gate as file-based project config. Git config can carry remotely-authored content through include/includeIf (a cloned dotfiles repo, for instance), so source alone is not a trust signal.
• Precedence belongs to git. Keys are read from the already-cached git config --list -z map — zero new subprocesses. Local overrides global; conditional includes work; worktrunk never sees scopes.
• Existing interfaces. .config/wt.toml, [projects."…"] overrides, and WORKTRUNK_PROJECT_CONFIG_PATH are untouched.

Limits in this first version

Values are strings, one per key. Fields needing other TOML types (step.copy-ignored.exclude, an array) are not expressible and error clearly when attempted. Keys must be lowercase — git's key model makes middle segments case-sensitive, and the schema's own spelling is lowercase. No write commands: git config already is the management interface.

Testing

Unit tests cover the key mapping: nesting, value/table conflicts, empty segments, loud failure on non-string fields. Integration tests cover source selection, the supersession warning firing exactly when a file is superseded, local-over-global precedence, include.path resolution, approval gating, and wt config show in human and JSON forms. The config docs page gained a "Private project config in git config" section, and all generated doc mirrors and help snapshots are refreshed.

[worktrunk-bot]

Reviewing as a draft — flagging anything that looks worth a quick fix. Mark ready for a full review.

Nicely structured — the mechanical key mapping, the all-or-nothing selection, and the consistent "name the source, keep the approval gate" treatment across every consumer (config show, hook show, diagnostic, approvals, create, alias) all hang together. The diagnostic path deliberately omitting values (only naming keys + the superseded file) is a good call given diagnose output gets pasted into public bug reports.

One functional gap in the wt step prune skip-hint, noted inline: the git_source_active → invoking_project_bytes = None change doesn't actually suppress the (different hooks on branch) annotation the way its comment claims — it inverts it for the supersession case. Details on the line.

[worktrunk-bot]

Just the new commit since the last review — mostly test coverage, plus one behavior change in the diagnose path worth a second look (inline).

[indexzero]

@max-sixty after reviewing this a few times, I have started using this as my default for wt locally as of today

Will run this from now on to shake loose any other bugs, but it feels solid

Curious to hear your thoughts! 🙏

[worktrunk-bot]

Full pass now that it's out of draft. The core is in good shape — mechanical key mapping, all-or-nothing selection, and the "name the source, keep the approval gate" treatment across every consumer are consistent, and both draft-review findings are properly fixed (the differs guard in prune is now on the computation, and the diagnostic keeps its explicit Err arm). Test coverage is unusually thorough for a config source: scope precedence, include.path, includeIf, the override kill switch, declined-approval non-execution, and alias discovery matching dispatch.

Not approving, on repo policy rather than on the code: the diff edits src/commands/step/prune.rs, which is wt step prune's removal driver (branch deletion via delete_branch_if_safe, worktree removal). The project's review rules hold any change reaching that surface for a human. Requesting @max-sixty.

Three things worth a look, plus inline suggestions.

--global × all-or-nothing is the sharp edge, and neither doc paragraph says it. The docs note that --global "puts a key in every repository" and, separately, that selection is all-or-nothing — but not the product: a single git config --global worktrunk.config.list.url … set for convenience silently switches every repository on the machine off its committed .config/wt.toml, dropping all project hooks. The supersession warning does fire, which is the right backstop, but a user reading only the docs won't see it coming. Suggestion inline.

config.worktree is not uniformly ignored. Both the module spec and the docs say a config.worktree value is "never consumed" because the bulk read runs from the common git dir. That holds for a linked worktree, but the main worktree's config.worktree lives at $GIT_COMMON_DIR/config.worktree, so the common-dir read does pick it up — this repo's own prewarm_git_config_from_common_dir docstring relies on exactly that ("the common dir … sees the full merged set", vs. a linked-worktree read "missing values set on the main worktree's config.worktree"). Under extensions.worktreeConfig, then, a key placed in the main worktree's worktree-scoped file supplies project config repository-wide — the opposite of what the reader is told to expect. Two inline suggestions.

The diagnostic's value omission is defeated inside the same artifact. config_show_output deliberately prints key names without values because "diagnose output is routinely pasted into public bug reports" — but the report's own trace section embeds the raw git config --list -z output, values included, as the integration test concedes in its scoping comment. That matters more than it would for an ordinary git key, because this source's stated purpose is private configuration and the triage path (running-tend) tells reporters to run wt -vv and gh gist create the bundle. Calling it pre-existing is fair for git config in general, but the values only get there because this feature put them there. Worth deciding between the two consistent endpoints: redact worktrunk.config.* values in the trace layer too, or drop the value omission and let the report say plainly that git config values are included (matching the module's Privacy section, which already lists "config files"). The current middle reads as a guarantee it doesn't deliver.

Smaller notes:

• Git lowercases the final key component, so user-chosen names get silently lowercased: worktrunk.config.aliases.Deploy lands as deploy (verified against git). Fine as behavior, but it isn't covered by "keys must be written in lowercase — exactly how the schema spells them", since alias names aren't schema-spelled. Folded into the docs suggestion.
• warn_superseded_project_file's "SET it only on emit" comment justifies itself with wt config create --project's born-superseded warning, but that warning is an independent eprintln! in create.rs and never consults this latch. The behavior is right; the reason given for it isn't. Inline.

[worktrunk-bot]

The rebase plus 690dcbd — all four open threads from the last pass read as properly addressed, and the fixes are accurate rather than cosmetic: the config.worktree correction now matches what prewarm_git_config_from_common_dir actually does, the --global product is spelled out with a workable mitigation (includeIf), and the latch comment states the reason it really has. I'm resolving those threads.

The trace redaction is the substantive addition and it's well-placed — a Cmd-level redact_logged_stdout that only touches the copy log_output writes, gated behind the existing log_enabled!(Debug) check so a normal run pays nothing, applied at all three git config --list -z sites. The -z framing (first \n per NUL-delimited entry is the key/value split) is the right parse, and leaving valueless and non-matching entries verbatim keeps it scoped to this namespace.

Two things on the new commit, both inline.

pipe_into honors the redactor on the stage that can't leak and drops it on the stage that can. The source's stdout is routed into the pipe, so its redactor is a no-op there — but the sink's stdout is captured (second_child.wait_with_output()) and logged, and it's passed None unconditionally. Every other field pipe_into can't support (stdin_data, timeout, external_label, directive_*_file) is guarded by an assert; this one is silently ignored. For a field whose entire job is keeping private bytes out of the bundle, silent-drop is the wrong failure direction.

The bundle-wide leak assertion can pass without proving anything. The loop's let … else { continue } skips a missing log silently, so if trace.log/subprocess.log were ever absent — or the config read stopped going through the traced path — the test still passes on diagnostic.md alone, which the earlier assertions already cover. The comment claims "the key name survives, and other config is intact," but nothing asserts either. A positive check that the redacted listing actually landed in the uncapped sink turns absence-of-value into evidence of redaction.

Not approving, same reason as last time rather than anything new in this commit: the diff still reaches src/commands/step/prune.rs, and the repo's review rules hold that surface for a human. @max-sixty is already requested.

[worktrunk-bot]

Full pass over the rebased head. Both findings from the last round are properly
closed: pipe_into now refuses a redactor on either stage rather than dropping
the sink's, and the bundle-wide leak assertion requires all three logs to exist
and positively proves the redacted listing reached subprocess.log, with a
non-worktrunk value still visible beside it.

Two new things, both inline.

wt config show --format json swallows the git-config read failure the other
two surfaces are careful to report. render_project_config propagates it with
? and says why — "swallowing it would render the file as active while actual
execution errors on the same read, and diagnostics must not disagree with
execution" — and config_show_output prints (git config read failed: …) for
the same reason. The JSON renderer reads it through unwrap_or_default(), so a
failed bulk read collapses into "no keys", drops into the file branch, and
reports "source": "file" with the file's config and invalid unset — while
ProjectConfig::load hard-errors on that same read, so wt merge in that state
fails. repo.project_config_path()? two lines below already propagates, so ?
is the adjacent convention here.

The parse error on the all-or-nothing hard fail points into a document the
user never wrote. TOML parse error at line 2, column 11 (from
git_config_source_invalid_value_fails_loudly.snap) is a location in the TOML
render_git_source_toml synthesizes; what the user set was a git config worktrunk.config.… key. Since selection is all-or-nothing and a parse failure
is deliberately fatal, this message is what stands between the user and every
wt command working again, so it should name the key rather than a synthetic
line number.

Not approving, for the standing reason rather than anything in this diff: the
change edits src/commands/step/prune.rs, prune's removal driver, which the
repo's review rules hold for a human. @max-sixty is already requested.

[worktrunk-bot]

Both suggestions from the last pass are applied as written and hold up. The JSON
report now propagates the bulk-read failure the way config_show_output and
ProjectConfig::load already do, so all three agree on that read and only
diagnostic.rs keeps its deliberate best-effort note. The parse error names the
worktrunk.config.* keys it was rendered from, keys only.

One thing the applied suggestion left behind, inline: the comment directly above
the changed line still describes that read as tolerant, so it now contradicts its
own sibling comment on the identical read.

[worktrunk-bot]

unwrap_or_default() is gone from the line below, but the comment above it still
says the read is tolerant — "a broken source sets invalid and reports null
config rather than aborting the report". That now describes only the parse
(render_git_source_toml + parse_json_config); the read itself aborts.

The sibling comment on the identical call in config_show_output gives the
opposite rationale — "A failed read propagates rather than defaulting to empty
— swallowing it would render the file as active while actual execution errors on
the same read, and diagnostics must not disagree with execution." Two comments in
one file disagreeing about one accessor is what invites the revert: the next
reader reaching for a report that always renders has this comment's authority for
putting unwrap_or_default() back.

Suggested change

	// Experimental git-config source (#3454): when any `worktrunk.config.*`
	// key exists it is the whole project config, with no on-disk path.
	// Parse it tolerantly like the file path below — a broken source
	// sets `invalid` and reports null config rather than aborting the
	// report — and name it as the active source.
	// Experimental git-config source (#3454): when any `worktrunk.config.*`
	// key exists it is the whole project config, with no on-disk path.
	// A failed read propagates, matching `config_show_output` and
	// `ProjectConfig::load` — swallowing it would report the file as
	// active while execution errors on the same read. An unparseable
	// source is still tolerated like the file path below: `invalid` is
	// set and the config reported null rather than aborting the report.