Driver
PR #335 (closes #317) refined the v1→v2 migration semantics in AgDR-0021 § H: onboarding.yaml now uses copy (cp -p) + git rm --cached + .gitignore add (was mv), while workspace/ keeps move semantics. The framework spec (the two skills + the AgDR + the test) is now aligned.
docs/multi-project.md § "Migrating from split-portfolio v1 to v2" was deliberately not touched in #335 to keep the PR scope tight. The manual recipe in that section still describes the older mv onboarding.yaml ... shape (lines 180, 516, 528-530, 533, 539, 544, 558, 570 per Rex's spot-check on PR #335). AgDR-0021 § H is now the source of truth; the manual recipe is a fallback that's diverged.
Low-priority docs follow-up; the manual recipe is a fallback path that operators rarely hit (the /update skill handles the migration automatically). But every day the prose diverges from the spec, an adopter following the manual path winds up with the older shape.
Scope
Single-file edit at docs/multi-project.md § "Migrating from split-portfolio v1 to v2" → § "What if you want to migrate by hand?":
- Update the
onboarding.yaml portion of the manual recipe — switch from mv onboarding.yaml "$SIBLING/onboarding.yaml" to:
cp -p onboarding.yaml "$SIBLING/onboarding.yaml"
git rm --cached onboarding.yaml 2>/dev/null || true
- Add
onboarding.yaml to .gitignore (already covered by the existing heredoc — verify it lands BEFORE the git rm --cached)
workspace/ block stays as-is (mv semantics unchanged)
- Update the prose around lines 180 ("v1 layout"-explanation paragraph) and 516 (the "v1 → v2 migration prompt" example output) to mention the copy semantics for onboarding + reference AgDR-0021 § H
- Update the post-migration commit guidance (lines 528-530, 533, 539, 544, 558, 570) — operator commits in BOTH the public fork (now staging a
.gitignore change + the marker + config-block additions, NO mv of onboarding.yaml) AND the private sibling repo (gets the copied onboarding.yaml)
Acceptance Criteria
Out of scope
- Updating any other doc that references the old
mv semantics (this PR scopes to multi-project.md only; if other docs diverge, file separate tickets)
- Adding a smoke test that grep-validates the prose matches the spec — overkill for a manual fallback recipe
- Reorganising the section structure (just align the prose with current spec)
Glossary
| Term |
Definition |
| Copy semantics (onboarding.yaml) |
cp -p to sibling + git rm --cached in public fork + add to public-fork .gitignore. Sibling holds canonical source of truth; public fork keeps a gitignored snapshot for legacy tooling |
| Move semantics (workspace/) |
mv to sibling. Size constraint — clones are potentially gigabytes; doubling disk usage makes no sense |
| Manual fallback recipe |
The "migrate by hand" prose in docs/multi-project.md for adopters on framework versions that predate /update's automatic v1→v2 step 8a. Should match AgDR-0021 § H but currently diverges |
| AgDR-0021 § H |
"v1→v2 migration semantics" — the new source of truth for per-file-class verbs landed via PR #335 |
Refs PR #335 / Rex review suggestion #1 (non-blocking follow-up)
Driver
PR #335 (closes #317) refined the v1→v2 migration semantics in
AgDR-0021 § H:onboarding.yamlnow uses copy (cp -p) +git rm --cached+.gitignoreadd (wasmv), whileworkspace/keeps move semantics. The framework spec (the two skills + the AgDR + the test) is now aligned.docs/multi-project.md§ "Migrating from split-portfolio v1 to v2" was deliberately not touched in #335 to keep the PR scope tight. The manual recipe in that section still describes the oldermv onboarding.yaml ...shape (lines 180, 516, 528-530, 533, 539, 544, 558, 570 per Rex's spot-check on PR #335). AgDR-0021 § H is now the source of truth; the manual recipe is a fallback that's diverged.Low-priority docs follow-up; the manual recipe is a fallback path that operators rarely hit (the
/updateskill handles the migration automatically). But every day the prose diverges from the spec, an adopter following the manual path winds up with the older shape.Scope
Single-file edit at
docs/multi-project.md§ "Migrating from split-portfolio v1 to v2" → § "What if you want to migrate by hand?":onboarding.yamlportion of the manual recipe — switch frommv onboarding.yaml "$SIBLING/onboarding.yaml"to:cp -p onboarding.yaml "$SIBLING/onboarding.yaml"git rm --cached onboarding.yaml 2>/dev/null || trueonboarding.yamlto.gitignore(already covered by the existing heredoc — verify it lands BEFORE thegit rm --cached)workspace/block stays as-is (mv semantics unchanged).gitignorechange + the marker + config-block additions, NOmvofonboarding.yaml) AND the private sibling repo (gets the copiedonboarding.yaml)Acceptance Criteria
docs/multi-project.md§ "What if you want to migrate by hand?" recipe matches AgDR-0021 § H (cp + git rm --cached + gitignore for onboarding; mv for workspace)mv onboarding.yaml)AgDR-0021 § Hfor the design rationaletest_split_portfolio_v2_migration.shuses (operator-verified, not automated — it's a prose recipe)Out of scope
mvsemantics (this PR scopes to multi-project.md only; if other docs diverge, file separate tickets)Glossary
cp -pto sibling +git rm --cachedin public fork + add to public-fork.gitignore. Sibling holds canonical source of truth; public fork keeps a gitignored snapshot for legacy toolingmvto sibling. Size constraint — clones are potentially gigabytes; doubling disk usage makes no sense/update's automatic v1→v2 step 8a. Should match AgDR-0021 § H but currently divergesRefs PR #335 / Rex review suggestion #1 (non-blocking follow-up)