"The room export is broken" is enough to start an investigation. It is not enough to tell an engineer which action failed, what should have happened or which setting matters.
For an internal support coordinator, the useful handoff is a reproduction note: one symptom, an explicit expected result, an observed result, a safe sequence and the limits of the tests. Keep the user's theory as a theory. A missing row does not establish a broken database query.
The MAJLS preparation pattern below is proposed, not a demonstrated product capability. It ends at a human-owned engineering handoff. It does not diagnose the cause, change records or deploy a fix.
Borrow the reporting discipline, not the project workflow
Mozilla's bug-writing guidance says a summary should identify the problem rather than suggest a solution.[1] It also asks reporters to separate observations from speculation and state whether reproduction is consistent, occasional or unavailable.[1]
Chromium's guidance calls for detailed replication steps and expected behaviour, and suggests a simplified test where one can be created.[2] Those are browser-project instructions. We adapt their evidence discipline to an illustrative internal application; we are not adopting their public trackers, release procedures or permission to run tests on production.
Expected behaviour needs a source too. If a user expects an export to include every row ever stored, but the agreed requirement says "current filtered rows," the difference may be a requirement question. Attach the requirement or leave the expectation unresolved rather than declaring a defect from preference alone.
Filled example: a filtered room export
All products, builds, people, logs and outcomes in this example are synthetic. No application was tested to produce them. Support coordinator Omar receives intake IN-11: "After sorting the room list, one room disappears from the CSV. Maybe the database cannot handle the name."
The allowed sandbox has only two fixture rooms, R1 Cedar and R2 Birch. Requirement EX-01, paragraph 2, says: "Export contains every currently displayed filtered room, one data row per room; the header is additional." The filter selects both rooms. Product build demo-17, TestBrowser demo-4 and TestOS demo-1 are symbolic environment labels, not real supported versions.
Omar records these hypothetical attempts. Each executed attempt begins from a fresh sandbox session with the same fixture and filter. Row counts exclude the CSV header. The only planned change is the sort direction.
| Attempt | Sort setting | Visible / exported data rows | Outcome | Evidence locator |
|---|---|---|---|---|
| T1 | Default, no explicit sort | 2 / 2 | Expected result | LOG-11:T1; CSV-T1 |
| T2 | Room name descending | 2 / 1 | Missing R2 Birch | LOG-11:T2; CSV-T2 |
| T3 | Room name descending, fresh repeat | 2 / 1 | Missing R2 Birch | LOG-11:T3; CSV-T3 |
| T4 | Room name ascending | 2 / 2 | Expected result | LOG-11:T4; CSV-T4 |
| T5 | Requested older build | Not run | Build unavailable | LOG-11:T5; Omar owns request |
Two executed descending-sort attempts show the same symptom. That is not a claim about all users, browsers or builds. T5 is not a pass, a failure or evidence of when the problem started.
Template: the complete engineering note
Omar's pending handoff to engineer Leila contains:
- Summary: "Descending room sort omits Birch from filtered CSV export."
- Scope and environment: the two-room fixture only; sandbox build demo-17, TestBrowser demo-4, TestOS demo-1; filter includes R1 and R2. Other environments untested.
- Steps: start a fresh authorised sandbox session; load fixture ROOMS-11; open the room list; apply the two-room filter; sort room name descending; select Export CSV; count data rows and compare room IDs with the visible list.
- Expected result: two data rows, R1 and R2, supported by EX-01 paragraph 2. No claim about export ordering, which EX-01 does not specify.
- Actual result: both IDs visible; CSV contains R1 only. T2 and T3 match. Default and ascending controls export both IDs.
- Evidence and limits: LOG-11:T1–T5 and CSV-T1–T4 retained in the authorised internal store. T5 not run. No error log, network trace or root cause established.
- Hypothesis: intake's database/name explanation is untested. Proposed next question: Leila checks export behaviour under the descending setting, without treating that explanation as confirmed.
- Owner and acceptance: Omar prepared the note; Leila's receipt and technical triage are pending. Support has not promised a repair date or marked the issue fixed.
Each step specifies an action, not just an intention such as "try the export." Keep the fixture small enough to compare the exact room IDs, but do not strip out a setting that the symptom needs. Mozilla recommends reporting precise observed and expected results separately.[1]
A screenshot could help an engineer see the selected setting; it would not prove the content of a downloaded CSV. Chromium recommends screenshots when helpful.[2] In this case, keep the actual fixture export as the evidence for the missing ID.
Bound the preparation role
A proposed AI assistant may organise supplied notes, identify missing fields and draft the handoff. It must not invent an unrecorded test, convert "not run" to "passed," infer a root cause or send protected logs to a public tracker.
Leila, the named human engineering owner, must approve consequential production changes and external disclosure. The preparation role cannot approve those actions. Omar must obtain permission for any additional access or tests; this synthetic sandbox example does not authorise production reproduction. Suspected security exposure, destructive steps or personal data should stop ordinary testing and go to the designated private human response route.
For a read-only drafting pilot, measure baseline clarification requests and preparation time from comparable tickets. Test the five-attempt log, a missing requirement, a contradictory export and a sensitive attachment. Proposed targets are every step traceable to evidence, zero invented runs, all unknowns retained and every sensitive case held. Stop on absent permissions, conflicting evidence or an unsafe proposed step, not on a confidence score.
Exit requires a human to reproduce the note's evidence mapping and Leila to accept the handoff boundary. A correct draft is not proof that the software defect exists, has been fixed or is ready for deployment.