Requirement to code, on one record

One system from the requirement to the code, and back.

A requirement is governed, planned as work, handed to the agent with everything that constrains it, and verified by tests the agent and your CI report back. The pull request, the test run and the change are on the record. There is no second tool to re-enter them into.

  • Governed records
  • Work the agent can pick up
  • Traced to tests and code
WHAT GOVERNS NOW
FR-7C21A4RequirementAuthority
DEC-3A91F0Decisionaccepted
MCPAgent contextbinding only
TC-0B72E5Test casepassed
ST-118D4CStoryPR merged
A product view, not a brochure diagram

One requirement, and everything currently holding it in place.

The record on the left is a requirement. Everything on the right is what currently constrains and proves it: the criteria it must meet, the records it refines and is constrained by, the tests that verify it and the story that implements it. This is the view the agent is given a scoped copy of.

  • What it saysThe requirement in its Authority state, with its acceptance criteria as separate items.
  • What holds itRelations, constraints, decisions, tests and code, each connected explicitly rather than inferred.
  • What the agent getsThe same picture through get_work_context, with retired records left out.
Payments modernizationProject
Authority
FUNCTIONAL REQUIREMENTS12 Authority
FR-7C21A4 · FUNCTIONAL REQUIREMENT

Activate a subscription only after payment is confirmed

AUTHORITY

AC1 Paid capability is unavailable until the provider confirms the payment. AC2 A failed confirmation leaves the account on its current plan. AC3 Every activation is recorded with its provider reference.

Criteria3 of 3 met
Tests4 passed
ChangedToday
RELATIONS AND TRACE6 links
OBJ-5B03D8refinesReduce failed activations
PC-0A7E61constrained byCard data never stored
TC-0B72E5verifies AC1Integration test · passed
ST-118D4CimplementsPR #214 merged
The loop

Six steps, and no second system.

No single step here is novel. What is different is that they are one system, so nothing is lost between them and nothing has to be re-entered somewhere else to be tracked.

  1. Capture

    A setup wizard walks from the project brief to objectives, requirements and constraints — typed by hand, suggested by AI, or reconstructed from an existing codebase.

  2. Govern

    Records move from Draft to Approved to Authority on a review board, with acceptance criteria and relations checked on the way. A second approver can be required.

  3. Plan

    Epics serve objectives, stories implement requirements and cover their criteria. Boards enforce the flow, WIP limits and blocking reasons.

  4. Build with the agent

    The agent asks for its story's work context: the requirements, criteria, constraints, decisions and tests that apply, and what changed recently. Policy says what it may do alone.

  5. Verify

    Test cases verify criteria. CI and the agent report results; criteria turn Met or Not met, and a failing test keeps the story open.

  6. Trace

    Pull requests and commits link themselves by code, the story moves when the PR opens and merges, and every change lands in history.

Go deeper

Three parts of the loop worth a closer look.

The loop above is the shape. These are the three places where the detail matters most.

01

What governs now

How a record moves between Draft, Approved, Authority and Retired, and why the retired state does the real work.

Read it
02

Governed context

What the agent reads through MCP, what it may propose, and what the policy lets it do on its own.

Read it
03

Traceability and quality

How each acceptance criterion is tied to its tests, its work and its code, and what happens when a test fails.

Read it
Already halfway through a project?

Corpole can start from the code you already have.

Onboarding reads what the repository already says and proposes records for a person to confirm. Nothing it finds binds the agent until someone approves it.

01

Evidence first, guesses last

Deterministic extraction runs before any model. Sources are weighed in order: tests, then documents, then code, then commits.

02

Governance where the agent is working

Each code module gets a maturity level. Govern the area the agent is about to touch, not the whole estate on day one.

03

Advisory or enforced

Start with advice on ungoverned areas. Switch a project to an enforced gate when the records are ready to carry it.

When there is a team

The same records, shared with the right people.

One developer and one project need none of this. It appears when there are people and projects to manage.

01

Roles you define

Access from owner to viewer and auditor, plus roles such as product owner, analyst, architect, developer, tester and risk owner — redefine them from 18 permissions per account, several per person.

02

Projects for the people on them

A project is visible to the people added to it. Tenants can open a project to everyone in the tenant when that is the point.

03

Maker-checker when you need it

Switch on a second approval for records per tenant: the person who proposes cannot be the one who approves.

04

Several tenants, one account

Keep business units or clients apart in tenants under one account, and publish standards or glossary terms to all of them.

Connect your coding agent

One MCP server, three ways in.

Claude Code, claude.ai, Claude Desktop, Cursor and any MCP client read the same Authority records. Sign in with OAuth, pick a project, done.

01

Remote MCP server

Streamable HTTP at corpole.com/api/mcp, with OAuth or a project token. Listed in the official MCP Registry as com.corpole/requirements.

Connection guide
02

Claude Code plugin

/corpole:init, /corpole:context, /corpole:check and /corpole:onboard, plus a hook that checks each edit against the governed code areas.

Plugin and repository kit
03

GitHub check

Every pull request has to cite existing, non-retired requirements. A retired decision cannot come back through a merge.

How the check works
Start where the problem is

Find out what is currently steering your agent.

Connect one project. Onboarding returns the requirements, decisions and constraints that appear to govern it today, and asks you to confirm or retire each one.