Keep a Long Spoken Coding Request Recoverable Before You Send It

Keep reviewed parts of a spoken request as separate text notes before assembling the message you will send. Record an explicit correction beside the earlier clause it replaces. If a part has no retained wording, leave a visible gap and ask for a new decision instead of producing a smooth but invented request.

This is useful before a coding task has even received a complete instruction. A task handoff can point back to an existing decision or patch; here, part of the requirement itself may be missing.

One historical public issue report describes a long technical dictation that did not produce usable text. It is an individual report, not evidence of a current product defect, a recording-duration limit or a successful recovery method. The manual example below does not depend on that product's current controls.

Check what exists before calling it a checkpoint

Choose units of meaning that you can inspect: the goal, a correction, an open question or the requested action. There is no universal safe number of seconds per unit. A pause also does not establish that a tool ended recording, retained text or sent a message.

Keep these three questions separate:

A retained note is a checkpoint only to the extent that its contents and location have actually been checked. Use the ordinary save and review facilities you have established for your tool; this guide supplies no autosave, history or storage instructions for a particular app. If persistence is unknown, record that uncertainty before relying on it.

Follow four capture positions, including the missing one

The Alder Notes project and all wording below are invented teaching material. No audio was recorded, no speech recognizer produced these strings and no recovery was performed. U1–U4 identify order, not elapsed time. “Retained” describes the supplied fictional notes.

The speaker wants a design proposal for search inside one selected project. The text will eventually go to the design conversation Alder Notes / Search design. No sending occurs in this case.

U1 — goal and first matching rule. The complete authored spoken wording and the retained text are the same:

For Alder Notes, prepare a design proposal for search in the selected
project. A note should appear only when both its title and at least one
tag match the query. I want a proposal to compare, not a code change.

Its retained location is the fictional note CAPTURE-ALDER/U1. The design-only action and selected-project scope are usable, but the matching rule will be explicitly changed in U2.

U2 — a correction to one part of U1. Again, this complete authored wording is also the retained text:

Correction to U1: do not require both fields to match. A match in the
title OR at least one tag is enough. Include a note that matches both,
but show it once. Do not search the note body. Keep the selected-project
scope and the design-only request from U1.

Its retained location is CAPTURE-ALDER/U2. This is an explicit correction, not a general instruction to prefer every later sentence over every earlier one.

U3 — missing. There is no supplied spoken wording, transcript, recording or retained location for this position. In the companion data, each is null. The speaker thinks they discussed display states, but that recollection does not establish the missing requirements. Do not write a sample U3 and then treat it as recovered input.

U4 — output and exact text. The complete authored wording and retained text are:

Compare two result-layout proposals and list the decisions still open.
I will supply the field names and selected project value as text. Keep
case handling, partial matching and result ordering as open questions;
do not decide them by guessing. Do not edit files, run the application
or send this request for me.

The retained location is CAPTURE-ALDER/U4. The speaker also supplies this exact text block there:

project_id
selected project value: p-alder
title
tags
body: excluded from search
Destination: Alder Notes / Search design

These are fictional identifiers, not inspected repository fields. Typing them makes their spelling available; it does not prove that a real project has that schema. In a real request, check the references you intend to supply. The existing technical-identifier guide covers combining spoken explanation with exact text.

Keep a correction ledger instead of flattening the notes

At this point, the capture record is complete about what it has and what it lacks:

The constraint ledger makes the correction more precise:

U2 does not erase U1's project scope or its design-only limit. Nor does U4's request for open questions authorize the writer to invent the missing display behavior. Keep the original notes separate from the assembled draft so a later reader can see both the correction and the gap.

Recognize two plausible bad assemblies

A flattened draft might say:

Prepare a search design in the selected project. Both the title and a tag
must match. A title or tag match is enough. Exclude body text. Compare
two layouts and do not edit files.

This is an authored bad assembly, not a verbatim copy of the retained notes. It removes U2's correction relationship and presents the old AND and new OR as simultaneous requirements. It also hides U3's absence. Keeping the no-edit sentence does not make the rest complete.

Another draft could resolve the contradiction and still invent the missing part:

Prepare a design for project p-alder. Match title OR any tag, including
both once; exclude body text. Show an empty result list before a query
and whenever there are no matches. Compare two layouts, leave case,
partial matching and ordering open, and do not edit files.

The display rule in that version is a guess. It may be a reasonable proposal in another conversation, but there is no retained source for adopting it here. A correct-looking OR rule cannot make the guessed display behavior recovered evidence.

Until the missing requirement is addressed, the next useful message is a question. It need not be a polished development request.

Ask again without claiming to recover the lost words

The question should identify the gap, separate the retained decisions and invite a fresh answer:

U1, U2 and U4 are retained. They establish selected-project scope,
inclusive title/tag matching, body exclusion and a design-only request.
U3 has no retained wording or audio. Your memory of discussing display
states does not supply an exact requirement.

What should the view show before a query, and after a nonempty query
has no matches? What should a clear-query action do, if you want one?
Are there any other requirements you want to supply now?
I will label your answer as a new decision, not recovered U3.

The fictional speaker supplies R3, a new typed statement:

New decision now: before a query, keep the existing list for the selected
project. For a nonempty query with no matches, show "No matching notes."
and a "Clear search" action. Clearing the query returns to that existing
project list. I have no other new requirement to add now.
This is a new instruction, not a claim about what the missing U3 said.

Retain it at CAPTURE-ALDER/R3. U3 remains missing in the original capture record. R3 supplies the current display decision; it does not reveal whether the lost section contained additional constraints. The speaker still needs to review the assembled request as what they want now.

The updated ledger has two distinct entries:

If no new answer arrives, keep the question open. You can explicitly ask for a discussion of the known requirements and the gap, but do not present the complete search design as authorized by missing input.

Assemble a current request from the available decisions

After checking R3 and the retained notes, the speaker can use this complete request:

Prepare a design proposal for Alder Notes project search in the
Alder Notes / Search design conversation. Do not implement it.

Scope and supplied fields:
- Search only notes with project_id = p-alder.
- Use title and tags as the searchable fields; exclude body.
- A title match OR at least one tag match is enough, including a note
  matching both. Show each matching note once.
- The earlier requirement that both title and a tag must match is replaced.

Current display decision:
- Before a query, retain the existing list for the selected project.
- After a nonempty query with no matches, show "No matching notes."
  and a "Clear search" action.
- Clearing the query returns to the existing selected-project list.

Return two result-layout proposals. Explain how each represents those
states and list the unresolved choices about case handling, partial
matching and result ordering. Do not select those policies silently.

These are my current instructions assembled from retained U1/U2/U4
and the newly supplied R3. U3 itself is still missing. R3 is a new
statement, not recovered audio; do not infer additional lost requirements.

Return a written comparison and open questions only. Do not edit files,
run the application or forward this request. The field names and project
value are supplied example references; identify a mismatch before adapting
this to a real project.

This draft preserves the changed conjunction and the action boundary. It includes the new display decision while leaving genuinely open matching questions open. Its completeness is about the current supplied instruction, not proof that every word of the lost section has been restored.

Before sending a real request, inspect both its meaning and its destination. If a send may already have occurred, check the intended conversation and its current message state before sending again. No send occurred in this teaching case. The conversation-selection guide owns that destination check; a note label alone does not perform it.

Reuse a small capture card and a missing-part card

Use one capture card per meaningful unit. Fill the state from what you can inspect, rather than from a recording icon or an assumed save setting.

Capture unit:
[Order label; not an invented timestamp.]

Available source:
[Audio actually available / visible text / retained text / none / unknown.]
Exact retained wording:
[Copy what exists. Leave missing wording empty.]
Retained location and check:
[Where it is; what you actually reopened or inspected, or not checked.]

Correction:
[Explicit earlier clause replaced, new wording and its source; or none.]
Still missing:
[Gap or unresolved meaning; do not reconstruct it from a guess.]
Current action boundary:
[Discussion / proposal / scoped implementation, as actually supplied.]

For an absent section, use a separate question:

Missing unit:
Retained material before and after it:
What is absent or unknown:
Unverified memory hint, if any:

Question about what is wanted now:
[Ask for the missing decision without implying you recovered its words.]
New speaker answer and reference:
[Leave blank until supplied; label it as a fresh statement.]

Original missing content status:
[Still missing unless actual retained material becomes available.]
Current request decision:
[Use the fresh statement / keep the question open / narrow the request.]
Before sending:
[Review current meaning, exact references, action limits and destination.]

The retained notes, correction history and missing-part question make the unfinished input inspectable. They give the speaker a concrete way to supply what is wanted now while leaving the unavailable past honestly unknown.