Verify C1.1 — Codebase Accessibility
Criterion Definition
| Level | Description |
|---|
| 0 | Code split across unlinked repos |
| 1 | Repos linked through submodules or other mechanisms |
| 2 | Monolith or Mono-repo |
Evidence to Gather
- Look at the project root structure to understand the overall layout and whether there is a single entry point.
- Read
README.md and assess whether this repository is part of a larger multi-repo setup.
- Check for dependencies and references to other repositories in documentation, build files, or configuration files.
- Check for any indicators of a multi-repo setup (gitmodules, symlinks, references to other repos).
- Inspect CI/CD workflows and build scripts for cross-repo checkout/copy patterns (for example
actions/checkout with repository: org/other-repo, git clone org/other-repo, or cp from externally checked-out repos).
- Inspect dependency/config manifests for explicit sibling-repo links (for example git URLs, path dependencies, workspace mappings, or automation keys/tokens used to fetch another repo).
Project-Context Requirement (Inbound Check)
Evaluate C1.1 from a story-delivery perspective, not only local repo structure.
- If this repository is mainly consumed by sibling repos as shared utilities/tooling, treat it as part of a split multi-repo codebase for end-to-end delivery.
- Consider only project-code coupling as inbound evidence. Ignore generic third-party reusable actions/tools unless they pull this repository's code.
Minimum Evidence Checklist
Before final scoring, confirm all checks below:
- Repo-internal layout (
README.md, root folders, app/module structure).
- Technical linking mechanisms (
.gitmodules, git subtree/workspace linking, checked-in path links).
- Cross-repo consumption evidence from workflows/build/docs (checkout/clone/copy/import of sibling repos).
Do not assign Level 2 unless checks 2, 3, and 4 show no cross-repo split of code ownership relevant to build/runtime/tooling and end-to-end story delivery.
Instructions
Gather the evidence described above and determine the fulfillment level for C1.1.
Scoring guide:
- Level 0: Code is split across unlinked repositories. This includes multi-repo setups that only reference each other in README/docs, cases where CI/build pulls code from sibling repos without submodule/subtree/workspace-style technical linking.
- Level 1: Repos are technically linked through submodules or equivalent mechanisms (for example git submodules, git subtree, or workspace-level linking checked into the repo).
- Level 2: Monolith or Mono-repo with no evidence that required project code is sourced from other repositories.
Disambiguation Rules
- A repository containing multiple internal packages/folders (for example
utils/, shared/, docs/) is not automatically Level 2.
- If another repo must be checked out/cloned/copied for implementing a user story end to end, treat as split codebase and score Level 0 unless a formal technical linking mechanism justifies Level 1.
- If sibling repos depend on this repo for code needed in their build/deploy/runtime/test flows, this repo is not independently sufficient for end-to-end story delivery; prefer Level 0 unless formal technical linking justifies Level 1.
- In rationale, cite concrete file-level evidence (for example workflow file and step name) when cross-repo coupling is detected.
Report in exactly this format:
C1.1 — Codebase Accessibility
- Level: [0 / 1 / 2]
- Rationale: [one or two sentences citing the specific evidence]