Conductor Quick Start gstack template fails when generated repo has unborn HEAD #1176

Summary

Conductor Quick Start can fail when creating a new project from the gstack template because the setup/build path assumes git rev-parse HEAD works. In a brand-new generated repo before the first commit exists, HEAD is unborn, so git rev-parse HEAD exits 128 and the template setup aborts.

This is separate from the public garrytan/gstack repository itself: the upstream repo has a valid main HEAD. The failure is triggered by the generated Conductor workspace state during bootstrapping.

Observed Error

From Conductor while creating a new Quick Start project named test at /Users/jonas/conductor/repos with the gstack template:

Installing gstack...
error: script "build" exited with code 128
'git <command> [<revision>...] -- [<file>...]'
Use '--' to separate paths from revisions, like this:
fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
Node server bundle ready: /Users/jonas/conductor/repos/test/.claude/skills/gstack/browse/dist/server-node.mjs

Likely Setup Path

Current main appears to route Conductor setup like this:

• conductor.json runs bin/dev-setup
• bin/dev-setup creates .claude/skills/gstack -> repo root
• bin/dev-setup calls .claude/skills/gstack/setup
• setup runs bun run build when compiled browse output is missing or stale
• package.json writes git rev-parse HEAD into these version files:
  • browse/dist/.version
  • design/dist/.version
  • make-pdf/dist/.version

The hard failure is here in the build script:

"build": "... && git rev-parse HEAD > browse/dist/.version && git rev-parse HEAD > design/dist/.version && git rev-parse HEAD > make-pdf/dist/.version && ..."

Reproduction Mechanism

I reproduced the same Git failure mode locally by creating a new parent Git repo with no commits, then placing a gstack copy under .claude/skills/gstack without its own .git metadata. From inside that directory:

git rev-parse HEAD

returns:

fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

That matches the Conductor screenshot error and explains why a normal git clone of garrytan/gstack does not reproduce the issue: a normal clone has a resolved HEAD, while Conductor's generated repo can be in an unborn-HEAD state before the initial commit.

Suggested Fix

Make the build version fallback tolerate unborn Git repos. For example, centralize the version resolution once and write the fallback to all version files:

GSTACK_BUILD_VERSION="$(git rev-parse HEAD 2>/dev/null || printf unknown)"
printf '%s\n' "$GSTACK_BUILD_VERSION" > browse/dist/.version
printf '%s\n' "$GSTACK_BUILD_VERSION" > design/dist/.version
printf '%s\n' "$GSTACK_BUILD_VERSION" > make-pdf/dist/.version

Or inline the same fallback in package.json if keeping the build script single-line is preferred:

(git rev-parse HEAD 2>/dev/null || echo unknown) > browse/dist/.version
(git rev-parse HEAD 2>/dev/null || echo unknown) > design/dist/.version
(git rev-parse HEAD 2>/dev/null || echo unknown) > make-pdf/dist/.version

This should preserve normal cloned-repo behavior while allowing Conductor/new-repo bootstrapping before the first commit exists.

Workaround

Before setup runs, create an initial commit in the generated workspace:

git add -A
git commit -m "Initial commit"
bin/dev-setup

If there is nothing to commit, an empty commit should be enough to create HEAD:

git commit --allow-empty -m "Initialize workspace"
bin/dev-setup