Problem
Today, a new team member setting up a Base-managed workspace must know which repositories to clone, in what directory, and in what order. This knowledge lives in onboarding docs, not in machine-readable form. A basectl onboard flow for a team is impossible without a declarative workspace definition.
Proposed Design (Not Implementation)
This issue is for design and documentation only. It should produce a design document at docs/workspace-manifest.md and a candidate schema with explicit decisions on scope, trust model, and non-goals. No code should merge from this issue.
Candidate Schema
workspace:
name: banyanlabs
repos:
- name: base
url: git@github.com:codeforester/base.git
default_branch: master
required: true
- name: bankbuddy
url: git@github.com:codeforester/bankbuddy.git
default_branch: main
required: false
- name: banyanlabs
url: git@github.com:codeforester/banyanlabs.git
required: true
The workspace manifest should live outside any individual repo — probably at ~/work/workspace.yaml or at a URL that basectl onboard <url> can fetch.
Design Questions To Answer
- Where does the workspace manifest live? At a URL, in a special repo, or as a local file?
- How does Base authenticate to clone private repos? It should delegate to git/ssh — never own credentials.
- What happens when a repo already exists at the expected path? Pull? Leave alone? Error?
- What is the partial-failure model? If one repo fails to clone, do others proceed?
- Should the workspace manifest declare repo order (for setup sequencing) or just the set?
- Should
basectl workspace status be able to consume a workspace manifest without cloning?
- How is the workspace manifest versioned and distributed to a team?
Non-Goals For This Design
- Base should not become a secrets manager or SSH key manager.
- Base should not overwrite existing checkouts.
- Base should not assume all repos use the same language stack or Base manifest format.
- The workspace manifest should not duplicate what individual
base_manifest.yaml files declare.
Related
Problem
Today, a new team member setting up a Base-managed workspace must know which repositories to clone, in what directory, and in what order. This knowledge lives in onboarding docs, not in machine-readable form. A
basectl onboardflow for a team is impossible without a declarative workspace definition.Proposed Design (Not Implementation)
This issue is for design and documentation only. It should produce a design document at
docs/workspace-manifest.mdand a candidate schema with explicit decisions on scope, trust model, and non-goals. No code should merge from this issue.Candidate Schema
The workspace manifest should live outside any individual repo — probably at
~/work/workspace.yamlor at a URL thatbasectl onboard <url>can fetch.Design Questions To Answer
basectl workspace statusbe able to consume a workspace manifest without cloning?Non-Goals For This Design
base_manifest.yamlfiles declare.Related
basectl workspace status)basectl onboard(existing, scoped tobaseproject only today)