Skip to main content
← Back to list
01Issue
FeatureClosedExtensionsPublic
Assigneesskunk-ape

Relationships

⊘ blocks #2774

#2773 gatorwalk-factory: a workflow stage cannot say where its workflow lives (gap 3)

Opened by skunk-ape · 9/30/2026

This closes gap 3 in lifecycles/swamp-extensions.md:180-184. #2734 (Out of scope) and #2732 put it off.

What happens

A workflow block has a name and inputs only. swamp-extensions' verify workflows live in verification/ and run only with SWAMP_WORKFLOWS_DIR set to that directory. From a worktree, that has to be an absolute path to the worktree's verification/, with --repo-dir pointing at the main checkout. A relative path resolves against --repo-dir (agent-constraints/verification-conventions.md:133-145). The verify stage carries all of this as prose in command (lifecycles/swamp-extensions.yaml:533-539), with a <absolute path to the checkout> placeholder that the driver fills in by hand.

issue-lifecycle has the same problem. Its skill carries the same prose, so this is not a regression against it. It is still a hand step in the one stage that the attestation depends on.

Why it matters

A driver in a worktree that copies the command with a relative path runs the main checkout's verification/ definitions, not the change's. That fails later, in build-attestation or CI's validate-attestation, which pin the workflow files. It does not fail at the stage. In a pilot run from a worktree, which is how this team works, this is the most likely hand mistake.

Fix direction

Decision for the implementer, possibly for Seth: fix it in gatorwalk or in swamp.

  • In gatorwalk: workflow: { name, dir }, with dir relative to the repository. The dispatch packet resolves it against the worktree the driver is in and prints the full command, env and --repo-dir included, so the driver runs the command as printed.
  • In swamp: workflows found in more than one directory, or a repo-level workflowsDir that works from worktrees. gatorwalk then needs nothing. This would be a swamp issue, and gap 3 would cite it.

Done when

  • The verify stage's packet gives a command that runs unchanged from the main checkout and from a worktree. verify_workflow_test.ts covers both.
  • Gap 3 is marked resolved, keeping its number.
02Bog Flow
✓OPEN✓TRIAGED✓IN PROGRESS◉CLOSED+ 1 MOREASSIGNED+ 2 MOREREVIEW+ 2 MORECODE_CONFORMANCE_REVIEW

Closed

10/1/2026, 6:16:15 PM

No activity in this phase yet.

03Sludge Pulse
skunk-ape assigned skunk-ape10/1/2026, 3:33:12 PM
skunk-ape linked blocked by #27729/30/2026, 3:58:43 PM
skunk-ape marked as blocked9/30/2026, 3:58:43 PM
skunk-ape linked blocks #27749/30/2026, 3:58:43 PM
skunk-ape removed blocked by #277210/1/2026, 3:28:38 PM
skunk-ape unblocked automatically10/1/2026, 3:28:38 PM
Editable. Press Enter to edit.

skunk-ape commented 10/1/2026, 6:16:15 PM

Dropping this for now. #2842 removed the swamp-club-swamp-extensions definition and its gap list from the repo, so the verify stage this issue fixes no longer exists here. Revisit if the team adopts gatorwalk for swamp-club work.

What was learned, for that rebuild: a stage command that runs as printed from the main checkout or a worktree sets SWAMP_WORKFLOWS_DIR to the output of git rev-parse --show-toplevel followed by /verification, and passes --repo-dir as the parent directory of git rev-parse --path-format=absolute --git-common-dir, both quoted. That assumes an ordinary checkout or worktree and git 2.31 or later. An integration test that ran this command from both places with differing stub workflows, reading each run's evaluated workflow, caught a relative SWAMP_WORKFLOWS_DIR. The swamp-side fix that would remove the git coupling is #2908.

Sign in to post a ripple.