The snapshot/ toolkit (state/secrets/manifest capture + restore) is currently built against the existing single-$ORG + flat $REPOS_DIR identity model. The RepoMan architecture (see the repoman-architecture spec, and discussion #62) is moving that model to per-repo {owner, name} tuples with owner-namespaced clone directories.
Snapshotting is a downstream consumer of this identity model, so it will need to follow once RepoMan stabilizes. This issue tracks that alignment.
Why the snapshot toolkit is insulated today
The manifest records each repo's real git remote get-url origin and its branch as captured facts, not values re-derived from $ORG. Restore clones from that recorded origin. So a faithful restore of a captured repo is correct regardless of how RepoMan resolves ownership. RepoMan changes how the source list is discovered and where clones live, not what restoring a captured repo looks like. This is deliberate: keep the snapshot toolkit robust to the in-flight #62 decision rather than pre-building against an unmerged architecture.
What will need to change once RepoMan lands
- Reader:
core_repo_names / get_core_repos (org profile + core-repos.txt) → repoman_get_repos() yielding per-repo {owner, name} from ~/.repoman/repos.json.
- Clone target layout: flat
<repos_dir>/<name>/ → owner-namespaced <repos_dir>/<owner>/<name>/.
- Empty-origin fallback:
restore.sh currently falls back to $ORG/<name> when a repo has no recorded origin. With global $ORG removed, that heuristic no longer holds; empty-origin repos should instead be flagged as unrecoverable (no origin recorded → cannot reconstruct clone URL).
- Manifest schema: consider recording
{owner, name} explicitly alongside origin, rather than deriving owner from the origin URL at restore time.
Dependency / sequencing
Blocked on RepoMan reaching a stable enough state that downstream consumers don't churn with its changes. No action needed in the snapshot toolkit until then; the recorded-origin design keeps current captures/restores valid in the meantime.
Assisted-By: Claude Code
The
snapshot/toolkit (state/secrets/manifest capture + restore) is currently built against the existing single-$ORG+ flat$REPOS_DIRidentity model. The RepoMan architecture (see therepoman-architecturespec, and discussion #62) is moving that model to per-repo{owner, name}tuples with owner-namespaced clone directories.Snapshotting is a downstream consumer of this identity model, so it will need to follow once RepoMan stabilizes. This issue tracks that alignment.
Why the snapshot toolkit is insulated today
The manifest records each repo's real
git remote get-url originand its branch as captured facts, not values re-derived from$ORG. Restore clones from that recorded origin. So a faithful restore of a captured repo is correct regardless of how RepoMan resolves ownership. RepoMan changes how the source list is discovered and where clones live, not what restoring a captured repo looks like. This is deliberate: keep the snapshot toolkit robust to the in-flight #62 decision rather than pre-building against an unmerged architecture.What will need to change once RepoMan lands
core_repo_names/get_core_repos(org profile +core-repos.txt) →repoman_get_repos()yielding per-repo{owner, name}from~/.repoman/repos.json.<repos_dir>/<name>/→ owner-namespaced<repos_dir>/<owner>/<name>/.restore.shcurrently falls back to$ORG/<name>when a repo has no recorded origin. With global$ORGremoved, that heuristic no longer holds; empty-origin repos should instead be flagged as unrecoverable (no origin recorded → cannot reconstruct clone URL).{owner, name}explicitly alongsideorigin, rather than deriving owner from the origin URL at restore time.Dependency / sequencing
Blocked on RepoMan reaching a stable enough state that downstream consumers don't churn with its changes. No action needed in the snapshot toolkit until then; the recorded-origin design keeps current captures/restores valid in the meantime.
Assisted-By: Claude Code