Problem
An empty repo under a customer's account is not something contributors can work. The value
we add at creation time is that the repo is set up correctly from commit zero — CI, test
harness, conventions, and gate configuration.
Scope
- Initial commit: project structure, test harness, CI workflow, contribution conventions,
issue templates — the setup the gate assumes exists
- Write the repo's
repository_settings row with the gate configuration this project
should run under (the table is already keyed on repo_full_name with per-gate modes, so
this is configuration, not new schema)
- Install / verify the GitHub App on the new repo so ORB can act on it
- Scaffold variants by project type where they differ meaningfully (service, CLI, library),
starting with one and expanding only when a second is needed
Acceptance
A freshly created APR repo passes its own CI on the initial commit and is immediately
workable by a contributor with no manual setup.
Note
This is where "we set it up properly" becomes real. The scaffold's quality directly bounds
first-pass merge rate for everything built on top of it.
Problem
An empty repo under a customer's account is not something contributors can work. The value
we add at creation time is that the repo is set up correctly from commit zero — CI, test
harness, conventions, and gate configuration.
Scope
issue templates — the setup the gate assumes exists
repository_settingsrow with the gate configuration this projectshould run under (the table is already keyed on
repo_full_namewith per-gate modes, sothis is configuration, not new schema)
starting with one and expanding only when a second is needed
Acceptance
A freshly created APR repo passes its own CI on the initial commit and is immediately
workable by a contributor with no manual setup.
Note
This is where "we set it up properly" becomes real. The scaffold's quality directly bounds
first-pass merge rate for everything built on top of it.