Component
A part of the solution that is built and delivered on its own: a web app, a mobile app, a service. Its code lives in one or more repositories.
What it is
A solution has a main component and can have more. Each component has its own repositories (on GitHub or GitLab; a folder of a monorepo can belong to a component), its own onboarded code modules and its own technical design.
Why it matters
Real systems are rarely one codebase. Knowing which part a change touches tells people who owns it, which repository the code goes to and which technical design applies, and lets an old part and a new part be governed at different levels.
What goes wrong without it
- Two repositories both have a src/ folder and their modules get confused.
- A rule written for the mobile app is applied to the booking service.
- An old codebase that is still being onboarded holds back the new one.
What it gives an AI agent
An agent working in a repository gets the design and rules of that repository's component. The Corpole plugin tells Corpole which repository the agent is in, so findings, code checks and module rules land on the right component.
Example: Clinic Booking
| Weak | Strong |
|---|---|
| The code. | Clinic Booking has two components: "web" (the patient site, repository clinic/booking-web) and "calendar-sync" (the calendar service, a folder of the same repository). |
How it relates to the rest
- Part of a solution; holds repositories and code modules.
- Its technical design is kept as TDR design records.
- Can have its own authority tier; the solution's tier is the lowest of its components.
In Corpole
- Managed in Solution settings → Components; repositories are connected in Solution settings → Repositories and CI, each with its own webhook secret.
- Onboard each repository separately; module paths are unique per component.
- Work, requirements and design records can name the component they affect.