Software units
Why software units exist
As a codebase grows, its structure becomes harder to see. In both traditional and AI-assisted development, especially when several people and agents work in parallel, the shared understanding of what each part of the code does, why its boundaries exist and how it fits the product gradually fragments.
Requirements describe product behavior at a higher level, while repository files expose implementation at its lowest level. Neither provides a clear view of the software as a system of implementation responsibilities. Software units create that missing middle layer: closer to code than requirements, but more meaningful and stable than individual files.
Each software unit is a named, versioned implementation artifact that represents one architectural responsibility. It may contain one source file or a focused set of files that must be understood and changed together. Reqode connects this boundary to its Unit Type, development rules, related specifications, dependencies, commits and verification state.
The implementation layer between specifications and code
Software units replace a fragile set of file-level links with a navigable model of implementation ownership.
Requirements and specifications
Requirements explain the behavior and outcome. Focused UI, API, data and other specifications describe the product contract in detail.
Why and what should exist
Software unit
Stable identity, architectural role, Unit Type rules, file boundary, dependencies, linked specifications and current verification state.
What this code means and how it should change
Source files and commits
Repository paths identify the files that implement the Unit. Commits show how that implementation changes over time.
Where the behavior is implemented
A detailed example of requirements connected to backend and frontend software units and their repository files. Open the image to inspect the full map.
What lives inside a software unit
A Unit is more than a label on a folder. It keeps the implementation boundary and the context required to understand, change and verify it.
Identity and lifecycle
A stable key, name, subsystem, project domain, lifecycle status and branch-aware revisions preserve the Unit's identity as the implementation evolves.
Files and boundaries
Normalized repository paths define the files that belong to the Unit. One Unit can represent a single file or a composite implementation artifact.
Architecture contract
The subsystem Code Manifest, Unit Type rules and Unit-Specific Implementation Guidelines tell people and agents how this implementation role should be built.
Connected evidence
Related specifications, dependencies, consumers, commits, sync state, verification results and Findings expose the wider implementation context.
One concept, different code shapes
Unit boundaries follow architectural responsibility, not a universal file count or folder convention. Unit Type rules define the right shape for each project.
Sign-up form component
/components/auth/useSignupForm.ts
/components/auth/SignupForm.test.ts
The component, its focused behavior and its test can be understood as one implementation boundary when the Unit Type defines them as a composite Unit.
Register user action
RegisterUserAction.php
A Unit can also be one implementation file. Its Unit Type still supplies naming, placement, dependency and behavior constraints.
Billing provider adapter
/billing/billing-contract.ts
/billing/BillingClient.test.ts
Several files can form one adapter when they jointly implement the same boundary. Imports alone do not merge unrelated responsibilities into the Unit.
These examples are illustrative. Each project defines its own Unit Types and composition rules.
Software units through the project lifecycle
The same implementation model supports codebase onboarding, feature delivery, review and long-term maintenance in the selected project branch.
Discover implementation structure
Connect repositories by subsystem and branch. Unit Discovery can map selected files to existing or new Units, select applicable Unit Types and refresh direct dependencies.
Define the affected implementation
Connect product specifications to the Units that implement them. For new behavior, define the intended Unit role and boundary before or during implementation.
Deliver focused context
Engineers and AI coding agents receive the applicable manifest, Unit Type rules, Unit-specific guidance, related specifications, files and dependencies instead of searching the whole repository.
Trace and verify the result
Inspect commits that touched the Unit, check alignment with linked specifications and compliance with implementation rules, then turn confirmed problems into Findings.
Give a coding agent an implementation anchor, not a repository dump
Reqode MCP can start from a source-file path, resolve the owning software unit and let the agent follow only the connected context required for the task.
Use Reqode MCP as the source of truth. Update /components/auth/SignupForm.vue for CR-123.
The context that applies now
- Current project, subsystem and branch
- Owning software unit and Unit Type
- Subsystem, type and Unit-specific rules
- Linked specifications, files and direct dependencies
MCP access is read-only, so accepted project context stays explicit and reviewable.
Explore the workflows built on software units
Software units connect several Reqode capabilities into one implementation feedback loop.
Architecture Governance
Define subsystem guidance, Unit Type rules and implementation patterns that apply to each Unit.
Specs ↔ Code Alignment
Compare a Unit's implementation with its directly linked specifications and explain confirmed divergence.
Continuous Verification
Run focused checks and preserve confirmed alignment or architecture problems as actionable Findings.
MCP for Coding Agents
Deliver current architecture, specification and Unit context to the coding agent working on the change.
Give every engineer and coding agent the implementation context that applies now
Connect product meaning, architecture decisions and source code through a stable implementation model.