docs(#143): document split-portfolio mode + add /setup privacy gate#144
Merged
Conversation
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
Closes the silent privacy bug for adopters on GitHub Free with any private project. Today's
docs/multi-project.mdinstructs them to fork apexyard and commitapexyard.projects.yaml+projects/<name>/to that fork — but a fork of a public repo cannot be made private on GitHub Free, so private project names land on a public GitHub repo the moment they push.This PR is the docs + setup-question minimum-viable starter:
single-forkdefault;split-portfoliofor adopters with privacy needs)/setupthat branches on the adopter's plan + project mixThe framework code refactor (
portfolio:config block inonboarding.yaml+ audit of every skill that hardcodes the registry path) is out of scope for this PR — tracked separately on #143. Until that lands, the split-portfolio mode works via manual symlinks (ln -s ../portfolio/apexyard.projects.yaml ...) which are documented here.Targets
devper the apexyard release-cut model.What changes
docs/multi-project.md(+170 lines, -3):TL;DR — single-fork mode (default)with a one-line pointer down~/ops/apexyard/+~/ops/portfolio/).claude/skills/setup/SKILL.md(+42 lines):test -L apexyard.projects.yaml).Why "docs + question" is enough for now
The split-portfolio mode is fully functional today with the two manual steps the docs describe (
ln -s ...+.gitignore). Every existing skill resolves through the symlinks transparently — no skill change is required for the pattern to work.Reference implementation:
atlas-apex/apexyard(public fork, slim) +atlas-apex/ops(private portfolio) — set up by the adopter who hit the trip-wire on 2026-05-02. Daily workflow has been working through symlinks for one full session without issue.Testing
markdownlint-cli2 docs/multi-project.md .claude/skills/setup/SKILL.md(CI runs it).#split-portfolio-mode--public-framework--private-portfolioresolves; external links (github.com/me2resh/apexyard) are not new./projectsresolves through the symlink at the end. (Verified by the reference adopter; capture as a test in a follow-up if useful.)/setupagain or follow the new section continue working exactly as before.Out of scope (tracked on #143)
portfolio:config block inonboarding.yamlschema withregistry,projects_dir,ideas_backlogfields/split-portfoliomigration helper skill — automates the recovery flow for existing single-fork adopters who hit the trip-wire (force-push history rewrite + redact issue/PR bodies + create private repo + symlink)/setup --resetor similar to opt-out of the privacy gate when re-running on a configured forkRefs
Glossary
git fetch-ing a public fork into a private one, and there's no way to make a fork private after the fact, so the registry's private project names end up published on a public GitHub repo./setupquestion that branches the configuration flow on whether any of the adopter's projects are private + which GitHub plan they're on. Single message, three answers, prevents the trip-wire by default.apexyard.projects.yamlandprojects/are symlinks pointing at the private portfolio repo. Skills resolve through the symlinks transparently. Theportfolio:config block (#143 follow-up) replaces this with a first-class config option.