fix(onboarding): vendor engine on /edpa:setup + refresh V2 install next-steps#51
Merged
Conversation
…xt-steps Fixes three fresh-install friction points found via a new E2E onboarding harness (tests/onboarding/), all on the path a Claude-Code-only user hits when they install the plugin and run /edpa:setup on a bare repo. 1. /edpa:setup never vendored the engine. project_setup.py now vendors scripts+schemas+templates+rules+VERSION into .edpa/engine/ as step 1 of main() (mirrors install.sh; rules come from plugin/rules, one level above edpa/, not edpa/rules). The CC path lost vendoring in 7223b40 ("stop vendoring into .claude/"); c8978f4 made a vendored .edpa/engine/ required 12 min later but wired it only into install.sh. Result: /edpa:setup produced a project referencing a .edpa/engine/scripts/ that never existed — CI (the --with-ci workflow) + documented CLI broke silently, masked by the MCP server running from the plugin cache. 2. install.sh "Next steps" printed stale V1 guidance ("provision GitHub Project ... push to GitHub Projects") and invoked project_setup.py with V1 args (--org/--repo/--project-title) that no longer exist and would error. Rewritten to V2 local-first, correct --with-ci/--with-hooks/--with-rules, plus filelock in the dependency hint. 3. Fresh edpa.yaml shipped the template's frozen methodology version. Both install.sh and project_setup.py now stamp governance.methodology to the live plugin version after seeding. Guards: tests/onboarding/ harness (pexpect + tmux, reproduces all paths deterministically), tests/test_project_setup_vendor.py (incl. --with-rules end-to-end), tests/test_install_sh_hygiene.py. Full suite: 564 passed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
jurby
added a commit
that referenced
this pull request
May 31, 2026
Engine now vendors on the /edpa:setup path (project_setup.py), V2 local-first install.sh "Next steps", and freshly seeded edpa.yaml methodology stamped to the live plugin version. See CHANGELOG.md and PR #51. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Three fresh-install onboarding friction points (EDPA 2.1.7), all on the path a Claude-Code-only user hits — install the plugin, run
/edpa:setupon a bare repo. Found via a new deterministic E2E harness (tests/onboarding/).1.
/edpa:setupnever vendored the engine 🐛 (silent, runtime)project_setup.pynow vendorsscripts+schemas+templates+rules+VERSIONinto.edpa/engine/as step 1 ofmain()(mirrorsinstall.sh).Why it regressed: the CC path lost vendoring in
7223b40("stop vendoring … into.claude/"); 12 min laterc8978f4made a vendored.edpa/engine/required but wired it only intoinstall.sh. Net:/edpa:setupproduced a project referencing a.edpa/engine/scripts/that never existed — the--with-ciworkflow it installs + the documented CLI broke, masked by the MCP server running from the plugin cache, so it surfaced only at CI/CLI time.Also fixed: rules were vendored from the wrong path (
plugin/edpa/rules) → corrected toplugin/rules(one level aboveedpa/), else--with-rulesstill failed with "Rules source dir missing".2.
install.sh"Next steps" was stale V1Removed "provision GitHub Project … push to GitHub Projects" and the broken V1 args
--org/--repo/--project-title(would error); now prints the V2 local-first flow with correct--with-ci --with-hooks --with-rules+filelockin the dep hint.3. Fresh
edpa.yamlshipped a frozen methodology versionBoth
install.shandproject_setup.pynow stampgovernance.methodologyto the live plugin version after seeding (was left at the template'sEDPA 1.22.1on a firstcp).Test plan
tests/onboarding/harness (pexpect + tmux) reproduces all onboarding paths deterministically — 5/5 green after the fix (Path B was failing before).tests/test_project_setup_vendor.py(incl.--with-rulesend-to-end + methodology stamp),tests/test_install_sh_hygiene.py.🤖 Generated with Claude Code