A Task records what was changed.
This is a suggested method. A tree connects product commitments, work and evidence. Choose the levels and questions that fit your workspace.
A Task records what was changed.
Every test of a criterion passes in its latest record.
The owner accepts the requirement and its green criteria.
A product that spans several repositories keeps one shared tree. Link work to the affected repositories.
Switching workspace changes the entire tree, requirements and discussions.
Workspaces can depend on each other. A node can stand for another workspace and show its status. An object can link to an object in another workspace. Each person sees only the workspaces that they can read.
A blocking link keeps the revision of its target. Work waits until the target, and everything that the target depends on, is green. A changed or archived target asks for a review. Work waits until a person pins the new revision or removes the link.
Suggested default tree: Domain → Capability → REQ → AC. Each workspace schema sets its own levels and the question each level answers.
The workspace schema selects permitted task parents. Each task has one parent. The default tree places tasks under acceptance criteria. One criterion can have several tasks. Other schemas can use different parent types.
Open an object to read its linked work. The workspace schema selects the permitted task parents.
The workspace schema defines the tree. The suggested default levels for commitments are domains and capabilities. Each type has a status rule: own, children, links or none. Owner acceptance is tracked separately.
Status circles show the current status. Each test is a node under its criterion. A test node is green when the latest record of its test passes, red when it fails, and grey when it has no record after the change. A criterion, a group or a requirement takes the highest tone of its children: red, orange, yellow, grey, green. A criterion without a test node is orange. A node that waits for a dependency or an answer is yellow. A node with the links rule takes its status from the objects that link to it. The workspace schema sets the list of status tones and their colours. An empty branch cannot be green. Task completion does not make a criterion green.
Connect your agent to the MCP endpoint https://joppa.otion.us/mcp
Open an object and choose the copy button. Paste the unique system ID into your agent chat to discuss it. Content changes, discussions, decisions and test nodes are recorded through joppa. MCP. On the board, a person sets priorities and dependencies. In Settings, the owner manages people and workspaces. The history icon opens a compact list of when, who and what changed. The timeline shows every change of the workspace in order.
File and comment icons are highlighted with a count when content exists. Empty icons stay thin, muted and disabled. Choose an active file icon to open the file list and read or download a file. Adding or removing files goes through your agent. The notes button opens descriptions and discussion. The copy button gives your agent only the permanent system ID.
Ask an agent to propose levels from the product documentation. The product owner reviews the boundaries, questions and owners.
Write requirements and tests together. Assign an owner who answers questions and reviews changes. Record decisions through MCP.
Assess readiness before work starts. Ask a named person for missing information. Independent work can proceed while other work awaits a decision.
A criterion lists the tests that prove it, by file and name. A member records the test results of each commit with joppa_record_results. Only these records decide the status. A completed Task alone proves nothing.
Each test node needs a recorded result. A failed test makes the criterion red. A test without a result keeps it grey. One criterion can have several test nodes. A test that proves several criteria has one node under each.
| Part | Example |
|---|---|
| Criterion | On iOS, a customer with an active subscription has access to paid features after signing in again. |
| Test name | tests/access.rs > paid_access_stays_after_sign_in, saved in the test list of the criterion. |
| Input and steps | A fixture with an active subscription. The test signs out, then signs in. |
| Assertion | The paid features open. The purchase screen does not appear. |
| Record | The test results of one commit, which a member records with joppa_record_results. |
Read green as “the listed tests pass on this commit”. The criterion shows the commit of each test result. Compare that commit with the deployed release before you treat a green card as evidence about production. A failed test keeps its failure message in the history of the criterion.
The example below follows one requirement. The agreed scope is iOS. Android and web require their own scope decision.
REQ: A customer with an active subscription keeps paid access after signing in again. AC: On iOS, paid features are available after sign-in for that customer.
The owner confirms the requirement. The agent assesses the criterion and marks it ready. Two Tasks deliver it: the backend returns the subscription entitlement, and the iOS app refreshes access after sign-in.
The agent saves the test list of the criterion. Both Tasks can be complete while the criterion is still grey: it waits for the recorded results.
Failed The backend reports an active subscription, but the app shows the purchase screen. The failed result stays in history.
The agent fixes the app. The agent runs every test again and records the results.
Passed Every listed test passes in its latest record. The requirement is ready for acceptance. Agent confidence, Task completion and silence cannot take the place of this decision.
A later commit changes the backend. The agent runs the same tests again and records the results. A test that fails makes the criterion red again.
Before launch, compare the release commit with the commit of the test results. The joppa. status shows only what the reports prove.
A change to the wording of a criterion makes it grey again. The next records decide its status. Earlier results stay in history.
The agent compares the implementation and the tests with the new wording. It updates them where necessary. Suitable test code can stay. Old results do not count for the new wording.
Comments do not create revisions or block work. An agent must not silently expand an iOS condition to Android or web. People decide changes to scope and policy.
| Situation | Next action |
|---|---|
| A test fails | The agent finds the cause and fixes it. The next record shows the new result. An older pass cannot hide a newer failure. |
| A listed test has no result | The criterion stays grey. The agent runs the test and records the result, or corrects the test list. |
| The deployed commit differs | The agent runs the tests on that commit and records the results. Old results stay in history and are not proof about the new commit. |
| The owner finds a defect | The owner records the reason. The agent adds a test that fails on the defect, then fixes it. Changed expected behavior needs new wording. |
| Requirements or policy conflict | The agent records the specific question and the person who decides. The affected criterion waits. Independent ready criteria can continue. |
History keeps wording, reports and decisions with their authors and times. Acceptance records what the owner considered sufficient. It does not prove that every possible condition is known.