The MVP is the same architecture with fewer moving parts: one intake record, one repro checklist, one engineering issue, and one record map that links the support ticket, Duckie run, and engineering issue.
MVP Goal
By the end of the MVP, Duckie should reliably answer:- What did the customer report?
- What customer, account, product, and environment context is available?
- Is the bug reproducible enough for engineering?
- What single missing detail blocks the handoff?
- What engineering issue should Duckie create or update?
- Which support ticket, Duckie run, and engineering issue belong together?
Minimal Flow
Build First
| Piece | What to build | Done when |
|---|---|---|
| Intake deployment | Trigger from support ticket, chat, email, or webhook. | Duckie receives new bug reports and stores the original ticket link. |
| Repro checklist | Check impact, product area, environment, steps, expected behavior, actual behavior, logs, and screenshots. | Each report gets a clear ready, missing_info, or duplicate_or_known_issue status. |
| Context lookup | Read customer, account, product usage, version, incident, and recent activity context. | Issue drafts include context without asking the customer for information the team can look up. |
| Bug intake agent | Interpret the messy report and draft repro steps or missing-info questions. | Repro-ready reports consistently produce useful issue content. |
| Issue creation | Create or update Linear or Jira issues for repro-ready reports. | Issues use consistent fields, labels, links, and ownership. |
| Record map | Store cross-system IDs in workflow state or a durable record. | The team can trace every issue back to the original ticket and Duckie run. |
Defer Until the MVP Works
Do not start with every bridge automated. Add these after the first loop is trusted:- Autonomous Slack engineering collaboration
- Engineering question routing back to customers
- Customer answer sync into Slack and Linear/Jira
- Automatic resolution follow-up
- Daily reporting and feedback agents
- Automatic high-severity issue creation
When to Expand
Move beyond the MVP when:- Missing-info questions are specific and useful
- Duplicate and known-incident checks are not creating noisy matches
- Severity, product area, and ownership recommendations are consistently correct
- Record links survive ticket updates, issue comments, and status changes
- The main remaining delays are handoffs that a two-way sync loop can remove
Next Pages
After the MVP:- Read the system map to see the full architecture.
- Build intake and repro gathering.
- Add the engineering issue workflow.
- Use the rollout plan before enabling live write paths.