# Archived-task filter: example feature specification

This is an illustrative specification to adapt to an existing application.
It is not a record of an implemented or tested product.

## Problem

Project members need to find archived tasks without mixing them into the
existing default list of active tasks.

## Existing behavior to verify in the target repository

- Task-list requests are scoped to the authenticated user's project access.
- Tasks already have an archived_at field.
- The list is paginated and has a documented stable ordering.
- The application already has a standard invalid-query response.

If inspection contradicts any assumption, revise this specification before
planning the implementation.

## Requirements

- R1: Omitting the status parameter preserves the existing active-only result.
- R2: status=active returns only tasks whose archived_at is null.
- R3: status=archived returns only tasks whose archived_at is not null.
- R4: Unsupported status values use the application's standard invalid-query
  response; they never silently expand the result.
- R5: The filter never broadens which projects or tasks the current user can see.
- R6: Filtering happens before pagination and result-count computation.
- R7: Changing the filter resets the page to the first page and preserves the
  selected filter in the URL for reload and navigation.
- R8: The interface distinguishes loading, empty, and failed requests.

## Non-goals

No archive/unarchive mutations, bulk actions, cross-project search, new roles,
database engine change, or global redesign of the task list.

## Evidence before acceptance

Map each requirement to a focused test or observed user journey. Include:
- A legacy request with no status parameter.
- Multiple pages with a mix of active and archived tasks.
- A user without access to the other project's tasks.
- An unsupported status value.
- An empty archived result.
- A failed request that must not look like an empty result.

## Change control

When a requirement changes, record the reason, update the affected acceptance
cases, and review the implementation plan and dependencies again. Do not rewrite
expected outcomes simply to make the current implementation pass.