From Support Ticket to Shipped Feature

This guide follows one support ticket through the Pathmode workflow. The coding agent proposes, the product manager judges, the agent builds the revision that was authorized, and the merge records that it shipped.

It is one concrete pass through the product intent loop of an AI-native SDLC: Sense the evidence, Decide what deserves attention, Specify the outcome, and Learn whether it happened after the execution loop ships.

Two people take part: a product manager who decides what should happen, and an engineer whose coding agent works in the repository. One person can do both jobs.

The Starting Point: Raw Friction

This support ticket lands in your Intercom queue:

It is real pain in the customer's own words. It is also ambiguous. "The button does nothing" could mean the export failed, or that it is running with no sign of progress. Those are two different builds.

With the support integration connected (Intercom or Zendesk), Pathmode extracts the ticket into the Evidence Inbox as a friction signal, with a severity, a sentiment, and a link back to the conversation. It is marked Unreviewed.

Extraction is capture, not judgment. Nothing is backed until a person says so.

No integration? The agent attaches the ticket in Step 3, and it is filed the same way: unreviewed.

The product manager's brief stays where it already lives: the ticket, plus a line in the team's tracker saying this is the next fix. The engineer pastes it into the coding agent and asks for an intent.

The agent runs check_intent_readiness first. There is no intent.md for this change yet, so it reads the export code and drafts one. Where the ticket leaves a consequential behavior undecided, the agent does not guess. It records a product choice:

The behavior that depends on this choice stays out of the required outcomes until someone answers it. Here is a trimmed version of the body the agent saves as intent.md, with intent_save and localDraft: true:

## Objective
Customers who click Export get their data or a clear reason why not. Today a
slow or failed export shows nothing, so customers retry for minutes and miss
the report they needed.

## Outcomes
- [ ] Clicking Export shows progress within one second
- [ ] An export under 1,000 rows downloads within 10 seconds
- [ ] A failed export shows an error message

## Scope
**In scope:**
- The Export button and its progress and error states
**Out of scope:**
- Changing the export file format

## Constraints
- Never start a second export while one is already running for the same account

## Edge Cases
- **The customer clicks Export twice**: one export runs, and the second click shows its progress
- **The export fails midway**: no partial file downloads

## Health Metrics
- Export success rate does not drop below its current baseline

## Verification
_A feedback loop, not just a test list._
**Fastest check**:
- [ ] Unit test: the export handler rejects a duplicate request for the same account
**Shipped signal**:
- [ ] Support tickets tagged "export" per week fall after release
**Regression guard**:
- [ ] Existing CSV exports still produce byte-identical files
**Automated test**:
- [ ] End-to-end: click Export on a 900-row account and receive the file within 10 seconds

The agent reruns preflight, explains the open choice, and stops. It has not written any code.

A workspace member opens repository setup and runs the one-time adopt command from the project root. Adoption carries the draft and its open choice into the workspace for review.

The agent then calls attach_original_request with the ticket's exact words and its link, and shares the review link. The ticket is attached word for word, because a summary written by the agent is not a substitute for the words it was asked to interpret.

The product manager opens the review link. The ticket sits beside What the agent understood, so the comparison is direct: does this proposal solve what the customer hit?

Two things need a decision:

1. The product choice. Most of this team's exports finish in seconds and customers wait on the page, so the product manager chooses Accept recommendation. Had they wanted email delivery, Suggest a change would record their answer, their reason, the trade-off they accept, and what would reopen the decision.
2. A correction. "A failed export shows an error message" is the exact failure the customer described: something happens, and they still cannot act. The product manager chooses Correct beside that outcome and writes: A failed export says why it failed and offers a retry.

Then the backing. In the Evidence Inbox, they open the ticket, choose Use as backing, and pick the claim it supports: the objective. The signal is reviewed and anchored in one action, stamped with their name and the time. The objective now reads Backed. The outcomes read No evidence, which is honest: one ticket shows the pain, not the right target time.

The answer and the correction are requests to the repository agent. Nothing is authorized yet.

The agent reads each request and applies it with intent_save, passing the request's changeRequestId and the baseRepoBodyRevision it was made against. The body gets a new revision. The accepted choice brings its behavior into the outcomes: An export that runs past 10 seconds keeps showing progress and delivers the file on the page.

The product manager reviews the revision: the corrected outcome first, then the whole proposal. With no open choices and no open corrections, they choose Authorize implementation. Pathmode records that decision for the whole proposal at that exact revision. Any later edit to the body is a new revision and needs authorizing again.

Before writing code, the agent calls get_intent and checks that the authorization matches the current revision. It fetches the full context with get_agent_prompt in execute mode, including any Constitution rules, and builds on a branch named intent/<id>.

With the pull request open, verify_implementation reads the diff from GitHub and grades each outcome, constraint, edge case, and verification check against the code, item by item. It is a reviewer reading the diff, not a test run. The checks in the spec still have to run.

If building shows the spec was wrong (say, exports over 1,000 rows need a background job the outcomes never mentioned), the agent records an implementation finding and proposes a correction instead of quietly building something different. See When the Build Contradicts the Spec.

The pull request names the intent, so merging it moves the intent to Shipped. Nobody marks it by hand.

Shipped is not solved. The merge proves the code landed; it does not prove customers can now export. That is what the shipped signal is for: if export tickets do not fall, the problem is not fixed, whatever the tests said. For the outcomes themselves, record what happened with record_outcome_measurement. Send the measured value with the expectation, such as the download time for a 900-row export, and the server computes whether the target was met instead of taking someone's word for it.

What remains is a trail: the customer's words, who judged them as backing and when, the choice and who made it, the exact revision that was authorized, the diff that was graded, and the merge. What the trail does not contain yet is proof that the pain is gone. That arrives when the numbers come back.

Designing that loop is its own discipline. See Verification Is a Feedback Loop for the five checks to write before you ship, not after.

The Difference

Without this loop, the ticket might:

• Get logged in Zendesk.
• Be summarized by a support lead.
• Get mentioned in a weekly meeting.
• Become a vague Jira ticket: "Fix export button".
• Get built as a spinner, when the real failure was an export that errored silently.

With it, the agent does the drafting, and the product manager spends their time on the one decision the ticket left open. The repo gets the decision. Pathmode keeps the evidence and judgment behind it.

Try It Yourself

Connect a support source, or paste your next real ticket into your coding agent with the Pathmode plugin installed, and review what it proposes. For the review screens in detail, see Your First Intent in Pathmode.