Software units
Why software units exist
When work spans several files, the agent needs to know which responsibility each part implements. Software units connect high-level specifications to the files that implement them.
A named, versioned Unit represents one architectural responsibility: a file or a focused set of files. It links Unit Type rules, specifications, dependencies, commits, and verification state.
The implementation layer between specifications and code
Navigate from intended behavior to implementation responsibility and source files.
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
One responsibility connects specifications to files
As example, an approval dialog links to the product behavior, UI, API and data it implements. Its software unit identifies the files that belong to that responsibility.
Architecture guidance reaches the same files
The unit belongs to a subsystem and follows a Unit Type. The subsystem Code Manifest, type rules and Unit-Specific Implementation Guidelines explain how its code should be built.
Illustrative example. Each project defines its own Unit Types, allowed specification links and file composition rules.
What lives inside a software unit
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
A composite Unit can group the component, its behavior, and tests when the Unit Type permits it.
Register user action
RegisterUserAction.php
A single-file Unit still follows its type’s naming, placement, dependency, and behavior rules.
Billing provider adapter
/billing/billing-contract.ts
/billing/BillingClient.test.ts
Files belong together when they implement one responsibility; imports alone do not define a Unit.
These examples are illustrative. Each project defines its own Unit Types and composition rules.
Software units through the project lifecycle
Use units for onboarding, feature work, and maintenance in the selected 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
Supply the manifest, type and unit guidance, specifications, files, and dependencies relevant to implementation.
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
MCP provides trace-file tool to resolve a mapped path to its units and connected context.
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
Use the implementation context
Explore how coding agents use software units and how the team checks implementation against specifications and architecture guidance.
