“Add a Cancel plan button” sounds straightforward. But when does access end? Can the customer resume? What happens if their payment is overdue?
This illustrative walkthrough continues the homepage's FN-412 example with scripted decisions, not a customer result.
Before the review: connect the repository
Start with a repository intent already adopted into a Pathmode workspace, and a reviewer with permission to request changes and authorize implementation. Installing the MCP server alone does not establish that connection.
If the intent is still local, a workspace member opens repository setup, chooses the product, and gives the adoption command to the repository agent. The agent completes adoption before sharing the review link. This is a human setup step, not something the agent silently does on the team's behalf.
The proposal retains the original request:
Add a Cancel plan button under Settings, Billing.
An example interpretation is:
Add the button. On click, cancel the subscription and end access immediately for the customer.
That is implementable, but the request never said cancellation should remove paid access immediately.
See the choices the request leaves open
Open the proposal and compare it with the attached request. The objective explains the problem; the choice list shows what needs an answer and what is waiting on another decision.
For this example, work through three choices:
| Choice | Example decision | What it depends on |
|---|---|---|
| When does access end? | End of the paid period. Keep access active through the period the customer already paid for. | Answer this first. |
| Can the customer resume? | Allow resuming before the paid period expires, without skipping or duplicating charges. After expiry, do not resume the cancelled subscription. | The access-timing answer. |
| What happens when payment is overdue? | Stop retries and renewal. Preserve any remaining paid access; end access immediately if the paid period has already expired. | The access-timing answer. |
These are decisions for this example, not universal cancellation policies. Read the recommendation, rationale, alternative, and trade-off before choosing. Keeping paid access means the system must still end access at period close; a cancellation click alone cannot finish that work.
For access timing, choose Accept recommendation if the wording matches what the team wants. Use Suggest a change to supply a different answer and its resulting behavior, rationale, and trade-off.
The answer creates a change request. The page shows it waiting for the repository agent. It has not changed intent.md, resolved dependent choices, or authorized implementation.
Leave undecided also goes through the repository agent. Once applied, that choice remains unresolved and continues to block authorization. It is not an implicit acceptance of the recommendation.
Have the agent apply the answer
The repository agent reads the change request, applies it to the intent, and sends back the resulting revision. If it cannot apply the request, inspect the reported reason; a refusal or waiting status is not an applied answer. If intent.md moved after you answered, that answer can no longer be applied by anyone. Pathmode marks the next step as yours. Ask again on the current proposal.
Once access timing is resolved, answer the dependent questions about resuming and overdue payments. In this example, the reviewer requests the behaviors in the table and the agent applies them.
If a dependent recommendation refers to an older parent answer, review the recorded parent decision and use Revise answer to make the dependent behavior match it. Do not accept a recommendation whose prerequisite no longer matches.
Review what changed
Return to What the agent changed after your correction and inspect the actual revised wording. An applied answer should be visible in the proposal, not only in a conversation or a pending request.
Check all three decisions together: paid access continues until period end, resuming is possible only before expiry, and overdue cancellation stops retries while respecting any remaining paid access.
Then review the surrounding outcomes, scope, constraints, failure cases, and verification. Resolving these three choices alone does not establish that the whole proposal is ready. If another choice remains open, leave it visible and continue the review.
When the proposal reflects the intended behavior and the remaining review requirements are satisfied, choose Authorize implementation. This is a separate signed-in action and applies to the exact repository revision being reviewed.
An accepted recommendation, a submitted correction, a guest comment, and a passing readiness check are not authorization. If the repository revision changes, the changed revision needs fresh authorization.
Carry the decision into the next coding session
The next connected coding session reads the current repository intent and the hosted review state. It should receive the same revision that was authorized, including the resolved choices and the resulting behavior. A copied prompt alone cannot establish that the current revision is authorized.
That receipt is the handoff. It does not prove the implementation follows the decisions. The engineer still needs to run checks for paid-period cancellation, resuming before and after expiry, overdue payments, and repeated requests.
Continue with Hand the authorized proposal to your coding agent for the engineer's side of the same example.
What carries forward
The original request remains attached to the proposal. The answers become change requests, then applied decisions in a repository revision. A separate authorization identifies the revision the agent may implement.
For setup from the beginning, follow Your First Intent in Pathmode.
Try this in your workspace.
Get the full flow in your own product: capture, review, back the claim, ship.
Start with Pathmode