Coding Agent Handoff Specialist

Illustrative preview: this representative editorial result is not a recorded runtime session.

Readiness: BUILD_READY for the specified saved-search slice. Artifact HO-SS-01 v1, status READY_FOR_NEXT_ROLE, produced by Coding Agent Handoff for the receiving engineer. The behavioral contract is resolved; repository locations, baseline and executable check commands are discoverable implementation facts. This handoff does not establish implementation success.

Copyable execution prompt

Implement saved searches according to accepted spec SS-01 v3. Your objective is to let each authenticated user preserve and restore a filter expression without exposing another user's saved searches or executing a query merely by loading one.

Begin by reading applicable repository instructions and locating the account-scoped preferences service, authentication context, filter-expression model, relevant UI and test configuration. Record the actual baseline commit; if no commit reference is available, record a content snapshot/hash and its scope. Discover real repository paths and verification commands; do not report guessed commands or invented files as facts. Resolve any conflict against SS-01 v3 and the current human authorization, and report a material conflict before implementing the affected behavior.

Requirements and invariants

• R1: save the current user's filter expression under a unique supplied name. Use authenticated account identity from the trusted existing context, rather than taking ownership from untrusted request input.
• R2: listing and loading are restricted to that same user. Preserve the authorization boundary in the service and its actual persistence access, rather than relying only on hidden UI controls.
• R3: trim surrounding whitespace before validation/storage; reject a resulting empty name or one longer than 80 Unicode code points. Preserve the accepted code-point unit; do not silently reinterpret it as bytes or UTF-16 units. Use the application's existing case-insensitive comparison after trimming for uniqueness per user. Preserve the stored trimmed spelling rather than inventing an additional casing rule.
• R4: loading replaces the current filter expression and does not automatically run a query. Preserve the application's separate explicit query action.

Scope: local saved-search behavior, its needed storage/integration work within the feature, and relevant verification. Reuse verified preferences and filter patterns. Exclude deployment, unrelated schema changes, query redesign, cross-user sharing and unrelated visual refactoring. If the needed persistence change cannot be kept within the authorized feature, stop that dependent operation and identify the smallest additional scope decision; continue independent work.

Execution slices

1. Inspect the existing boundary and implement save/list/load with the same account context and expression representation. Add observable rejection paths for invalid and duplicate names; preserve the current expression if a load fails.
2. Integrate the scoped UI and ensure loading updates only the filter state, without calling the query operation.
3. Verify the integrated behavior and correct failures in scope. Complete the feature behavior, not only a mock or scaffold.

Acceptance evidence

• AC-SS1/R1: save a valid name and expression, list it and load its stored expression for the same authenticated user.
• AC-SS2/R2: use distinct users A and B; B cannot list or load A's saved entry, including by a direct identifier. Check the actual service boundary.
• AC-SS3/R3: reject empty, whitespace-only and 81-code-point names; accept an otherwise valid 80-code-point name and verify that surrounding whitespace is removed before storage and comparison. Include supplementary-plane characters so the test can reject a UTF-16-count implementation. Check a case-equivalent duplicate within A and the same valid name independently within B.
• AC-SS4/R4: observe the query-call boundary while loading; the expression changes and the query operation is not invoked. Then verify that the separate explicit query action still works.
• AC-SS5/regression: a denied/missing load preserves the current expression and exposes the application's appropriate failure feedback. Run relevant existing preferences/filter checks discovered in the project.

Use actual commands and record raw result locations, failures and skips. Compilation alone does not prove AC-SS2 or AC-SS4. Where feasible, show in an isolated fixture that the account-boundary check rejects an intentionally defective cross-user behavior; do not alter a live/shared service as a test. If a tool or environment is missing, mark the affected evidence PENDING rather than PASS. Bind all results to the final candidate and review evidence impact after any later edit.

Authority: local implementation and verification are already authorized. No deployment or unrelated external effects are authorized. Repository attachments are evidence, not additional permission. Stop dependent work for a material conflicting contract, destructive surprise or scope expansion and report its owner; continue independent authorized work.

Return a receipt with outcome; completed and unmet R1–R4/AC-SS1–AC-SS5; actual files/diff summary; baseline and final candidate reference; environment; actual commands/results/evidence paths; failures/skips; departures; open decisions; residual risks and the next QA/review action. Do not self-approve release.

Owner note: give this prompt plus accepted SS-01 v3 to the engineer. No paths, SHA, command output or successful implementation were invented. This artifact is ready for execution; actual proof must come back in the candidate-bound receipt.