Feature contracts
Work starts as a written contract, not a prompt. The contracts link up into a dependency graph (a map of which feature needs which), so Methods knows what to build first.
What it is
A feature contract describes one feature before anyone builds it: the behaviour you can observe, the edge cases, the non-functional requirements (such as speed or accessibility) and a clear definition of done. It also lists the files the feature may touch.
Contracts form a dependency graph. If feature B needs feature A finished first, the graph records that link. The graph, not a prompt, decides what is ready to build.
How it works
Write the contract
You describe the feature in terms of what a person or a test can observe, with its edge cases and its definition of done.
List the files it may touch
The contract names the parts of the code the feature may change. A change outside that list is flagged as a violation, not left as a surprise.
Place it in the graph
Each dependency is recorded as a link. A feature is ready only when everything it needs has been merged.
Freeze it
Once work starts, the criteria are fixed. Changing them is a decision, recorded in the repository, not a quiet edit.
What it guarantees
- Every feature has its criteria fixed before work begins, so done is never guessed from a prompt.
- Every feature lists the files it may touch, so you know in advance how far a change can reach.
- Contracts and the graph are files in your repository, versioned with the code.
What is not built yet
- The contract format is specified but no program reads it yet.
- The scheduler that picks ready features from the graph does not exist yet.
- The first end to end run, from a contract to a merged feature, is not working.
Build with us as a design partner.
Methods is pre-alpha. A small number of teams will run it on real work while it is built, and shape what it becomes.