Skip to content

[Docs] docs/multi-project.md — align v1→v2 manual recipe with AgDR-0021 § H copy-onboarding semantics #336

@atlas-apex

Description

@atlas-apex

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

  • 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)
  • Prose around lines 180 + 516 references the copy semantics for onboarding
  • Post-migration commit guidance reflects the new staged state (no mv onboarding.yaml)
  • One-sentence pointer to AgDR-0021 § H for the design rationale
  • No regression on the rest of the doc (only the v1→v2 migration section + related references touched)
  • Manual recipe is testable end-to-end against the same fixtures test_split_portfolio_v2_migration.sh uses (operator-verified, not automated — it's a prose recipe)

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)

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3Low — ergonomics, nice-to-haveenhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions