The product owner approves
A spec planned from your requirements and documents, not from what the code happens to do today.
How it works
One spec, from the ask to the tester's sign-off.
Other tools cover one stretch of the way: a tracker holds the requirement, an agent writes the code, a quality tool scores it. KiwiPow runs one thread through all of it. A behaviour gets a stable identity when it is planned, and keeps it while it is approved, built, proven by a named test and accepted.
The loop, step by step
A behaviour gets a stable identity when it is planned, and keeps it while it is approved, built, proven by a named test and accepted. People own every decision along the way.
-
Server
Ask
Anyone in the team writes a feature in their own words.
-
Server
Plan
The AI planner turns it into a spec from your own documents and existing specs, and asks what only the requirement owner can settle.
-
Server
Review and approve
The product owner reviews in rounds and approves a numbered revision.
-
IDE
Build
A developer claims the feature. The agent maps the spec onto the code and builds exactly the approved behaviours.
-
IDE → Server
Talk back
Where the code disagrees with the spec, a decision is raised. The developer rules; departures reach the requirement owner.
-
IDE → Server
Prove
A named test proves each behaviour and edge case. Progress shows on the server as it happens.
-
Server
Accept
The tester accepts or reopens each behaviour against the tests that prove it.
-
Server
Close the circle
The accepted spec becomes the record of what the product does, and the documents it overtook are named.
The developer rules
Wherever the code disagrees with the spec, and a departure goes back to the requirement owner.
The tester accepts
Each behaviour, against the test that proves it. Not a ticket status.
Two products, one thread
How KiwiPow Server and KiwiPow IDE fit together
-
Server
Plan and approve
The product owner plans and approves a feature in KiwiPow Server.
-
IDE
Claim
A developer claims it in the IDE, which receives the spec with each behaviour's build state.
-
IDE
Map
The agent maps the spec onto the code and raises every disagreement as a decision.
-
IDE
Rule, build, prove
The developer rules, the agent builds, and each behaviour is proven by a test.
-
Server
Accept
Board and proofs reach the server as they move; the tester accepts behaviour by behaviour.
Compared
One license instead of your tracker, your editor and your quality tool
| Work trackers | AI code editors | KiwiPow | |
|---|---|---|---|
| Planning the work | Backlogs, sprints and boards | Not covered | The next approved feature from the product owner's ranked queue |
| Where the work starts | A ticket in free text | A prompt or an issue | A spec the product owner approved |
| Source of a requirement | Whoever wrote the ticket | The agent's reading of it | A cited section of your own documents |
| When code and requirement disagree | A comment, if anyone writes one | Left to the agent's judgement | A decision with proposals, routed to the owner |
| Proof it was built | A status someone set | A diff and the agent's summary | A named test per behaviour |
| Done means | The ticket is closed | The pull request is merged | The asker accepted every behaviour |
| Code health | A separate quality tool | A separate quality tool | Built into the IDE, from compiler-backed analyzers |
| What you pay for | Tracker seats | Editor seats, plus the quality tool | One license for all of it |
Read a finished feature before you plan your own
A ready-made demo product arrives with features already planned, built and accepted, so every stage of the loop can be read before anything is built.