Separate the Feature You Need from the Implementation You Suggest

Describe the user's desired result and its acceptance criteria before prescribing a technical design. Put implementation ideas in a separate section so an agent can investigate them without mistaking a guess for a requirement.

“Let me export the filtered work list” describes a user outcome. “Add a background worker and a new download table” proposes a means. Both can belong in a conversation, but they carry different authority. Keeping them separate makes it possible to reject an unnecessary component while preserving the requested feature.

Below is a complete fictional example: an initial mixed request, a revised requirement brief, two implementation plans, and a request for investigation before implementation. Its product, records, and business limits are invented teaching materials, rather than customer research or existing CueSpec capabilities.

Start with a request that mixes the two

Suppose a team member says:

Add Redis and a background worker so Export CSV downloads all the rows
matching the current filters, not just the visible page. Put an export
history table in the database and keep the download files for a month.
It must be instant and should be secure. Start building it.

There is a recognizable need inside this request: the current filters should determine export membership across pages. The rest needs sorting.

The background worker, cache product, database table, and file retention are proposed design choices. “Instant” lacks a checkable condition. “Secure” does not identify the permission boundary. Keeping files for a month also changes the feature's storage and access obligations, although the user may only need one download.

An agent that treats every phrase as equally settled could build the requested infrastructure without confirming the actual export behavior.

Rewrite the need as an independent brief

Here is the revised feature requirement for this fictional application:

# Feature need: Export the current filtered work list

## User and goal

A signed-in workspace member needs a CSV containing every work item
matching the filters currently applied to the list. Exporting only the
visible page is insufficient because the member uses the file for an
offline review of that filtered set.

## Membership

When the member clicks Export, freeze the applied filter values for that
request. When the server accepts the request, capture the matching records
they are permitted to export and their values. This server capture point
defines the export snapshot; it is not the earlier browser-click instant.
Later filter edits must not alter that export's membership. Delivered row
values must come from the same captured dataset for this example.

The result must include matching permitted rows across pagination.
Unchecked or partially typed filters that have not been applied do not
affect it. Export does not broaden access beyond the member's permissions.

## File content

Include the columns id, title, and status, in that order. Use the sample
below as the acceptance example. An empty result produces a CSV containing
the header row and no data rows.

## Feedback and limits

The interface must show that a request is being processed and provide an
explicit completion or failure state. It must not show success before a
download is available. If permissions change before delivery, fail this
export and ask the member to request a new one.

The first version must handle up to 5,000 permitted matching rows in this
fictional product. Above that chosen limit, show an explanation and ask
the member to narrow the filters. This limit is a requirement to validate,
not a measured capacity result. No completion-time promise is set yet.

## Outside the requested first version

Recurring exports, saved export history, email delivery, and month-long
download retention are not required. Existing retention and access rules
still apply to any implementation artifacts.

## Decisions still open

Where the captured dataset is assembled; whether processing is synchronous
or queued; how progress is represented; and what existing components can
be reused. Investigate these before selecting a design.

This brief makes “current filters” concrete. It also distinguishes the chosen example limit from a measured performance claim. A real team would choose the dataset size and acceptable waiting time using its actual users and constraints; the numbers here define an exercise.

The permission-change rule is deliberately explicit. Without it, one plan might deliver a captured file after access has changed while another might silently omit rows. Both could claim to satisfy “secure export,” even though their user-visible outcomes differ. The capture point is explicit too: freezing filters in the browser and capturing records on the server are separate events.

Give both plans the same acceptance example

The fictional member can export these four rows. They are the full permitted dataset for the example, not just one visible page:

The applied filters are status=open and queue=support. Pagination shows one matching row per page. The expected export is therefore two data rows, not one:

id,title,status
W101,Check labels,open
W104,Review inbox,open

This is a manually authored expected file. It has not been produced by an export implementation. Its job is to settle membership and column order before implementation begins. CSV handling for more complicated real values, including commas and line breaks, still needs an appropriate serializer and separate checks.

Now consider four acceptance situations:

An architecture that cannot explain these outcomes is not ready to be chosen, regardless of how familiar its components sound.

Plan A: Build the file during one request

The first candidate would let the server capture the authorized matching dataset and construct the CSV within the request that initiated export.

## Candidate A: Request-based export

1. Reuse the applied-filter representation, not the current page's rows.
2. On the server, evaluate authorization and capture the matching dataset
   within the chosen 5,000-row limit.
3. Serialize the captured values using a CSV serializer.
4. Recheck export permission immediately before delivery. If it changed,
   fail the request rather than delivering the captured file.
5. Return the download or an explicit error; the interface keeps a pending
   state until one of these outcomes is known.

Investigation needed: existing query/snapshot support, request duration
limits, memory use for the selected dataset, disconnect behavior, and
whether the required permission recheck is possible at delivery.

Why consider it: fewer new operational components if the existing request
path can meet the requirement. Suitability is not yet demonstrated.

This candidate does not assume that 5,000 rows are cheap to process. The row count alone cannot establish that: field sizes, query cost, serialization, and hosting limits also matter.

Plan B: Capture the dataset and process a queued job

The second candidate would separate dataset capture from file construction. That separation introduces a state model and temporary storage decisions.

## Candidate B: Queued export

1. Freeze filters for the initiating request, then authorize and capture
   the matching dataset on server acceptance, as in Candidate A.
2. Create a job referring to that captured dataset. A worker must not
   rerun mutable live filters later and call the result the same snapshot.
3. Serialize the captured values and record a completion or failure state.
4. Before delivery, recheck export permission. A change causes failure and
   a request for a new export, following the same rule as Candidate A.
5. Define access, expiry, deletion, retries, and cleanup for temporary
   snapshots and files before adopting this design.

Investigation needed: existing job facilities, temporary data policy,
progress retrieval, delivery authorization, and handling of abandoned jobs.

Why consider it: file construction can have a lifecycle separate from the
initiating request. The extra state and storage need explicit ownership;
they do not automatically provide a faster or safer implementation.

Both candidates satisfy the same intended user outcome on paper. Candidate B must solve an extra persistence problem; Candidate A must fit the relevant request path. Neither has been built or measured here. A third design could be preferable once the actual application is inspected.

Ask for investigation with an explicit stopping point

Use this complete request when the feature is understood but the implementation is not:

Investigate how to add the filtered CSV export described in the attached
feature brief. This turn is investigation and recommendation only.

First inspect how the application represents applied filters, enforces
export permissions, queries across pages, and captures consistent data.
Identify the relevant files and any existing export or job components.

Compare Candidate A (request-based construction) with Candidate B (captured
dataset plus queued construction) against the same four acceptance cases.
Treat Redis, a new table, and month-long retention from the original note
as suggestions, not requirements. Recommend reuse or another design when
the inspected evidence supports it.

Return a file-linked explanation, the smallest feasible implementation
plan, unresolved decisions, and the checks needed before claiming that
the plan meets the 5,000-row requirement. If a hosting limit is unknown,
state that rather than guessing a supported duration.

Do not edit files, install dependencies, create infrastructure, run a
production export, open a pull request, or deploy during this investigation.
Stop after the recommendation so we can choose the implementation scope.

GitHub's task guidance recommends clearly scoped problems and acceptance criteria, and describes research and planning before a pull request. The export brief and candidate plans here are our worked application of that advice.

Once a plan is chosen, turn that choice into an implementation request with the appropriate permission and delivery boundary. Keep the original user outcome visible: the selected infrastructure is useful only if it produces the correct export under the agreed conditions.