Add timestamped sighting reports and sighting history

[ismailbarankarasu]

Background

Community feedback highlighted that the time and location of each sighting are critical when a lost animal is still moving. A single “last seen” value on the original report may become outdated as new sightings occur.

People should be able to report that an animal was seen at a particular place and time. They should also be able to indicate whether the animal was only spotted or was safely contained while its owner was being located.

Goal

Add a sighting-report workflow for active lost-pet reports, including a chronological sighting history and a notification for the report owner.

Proposed Behavior

A user can add a sighting to an active lost report with:

• date and time observed;
• geographic location;
• optional public location description;
• optional notes;
• sighting status such as Spotted or SafelyContained.

The report owner can view a chronological history of sightings. New valid sightings should notify the owner through the existing in-app notification system.

Suggested API Shape

The final route names may follow existing project conventions. A possible design is:

POST /api/pet-reports/{petReportId}/sightings
GET /api/pet-reports/{petReportId}/sightings

Example request:

{
  "observedAt": "2026-08-31T18:30:00Z",
  "latitude": 40.195,
  "longitude": 29.06,
  "locationDescription": "Near the park entrance",
  "status": "Spotted",
  "notes": "Moving north; did not approach."
}

This is an illustrative contract, not a requirement to copy the property names exactly.

Domain and Architecture Guidance

• Domain: introduce a sighting entity/value model and enforce its invariants.
• Application: add commands, queries, handlers, response models, and FluentValidation.
• Persistence: add EF Core configuration and a migration; keep spatial data compatible with the existing location approach.
• API: expose thin endpoints that delegate to the application layer.
• Notifications: reuse the existing notification infrastructure.
• Do not put business rules or persistence logic directly in controllers.

Required Rules

• Sightings can only be added to eligible active lost-pet reports.
• ObservedAt cannot be unreasonably far in the future.
• Latitude and longitude must use the project’s existing geographic validation.
• Notes and location descriptions must have documented maximum lengths.
• Sightings must record who submitted them.
• Public responses must follow the privacy rules established for report locations.
• Adding a sighting must not change the original report owner.
• Duplicate or abusive reports should be considered in the design; a simple duplicate-prevention rule may be proposed.

Authorization and Privacy

• Define whether anonymous sightings are allowed; the first implementation should prefer authenticated users unless otherwise approved.
• Exact private addresses and reporter contact information must not appear in public responses.
• Only authorized users should access reporter identity when required for moderation.
• The report owner must not be able to edit another user’s sighting as if they submitted it.

Acceptance Criteria

• An eligible user can add a sighting to an active lost-pet report.
• Each sighting stores observation time, location, status, submitter, and optional notes.
• Invalid coordinates, future timestamps, and overlong text are rejected.
• Sightings cannot be added to found, resolved, cancelled, or archived reports.
• Sightings are returned in chronological order with ordering clearly documented.
• The owner receives one in-app notification for a valid new sighting.
• Public responses do not leak private address, contact, or reporter information.
• Automated tests cover successful creation, validation, authorization, ineligible reports, ordering, privacy, and notification behavior.
• Existing tests continue to pass.
• dotnet build RescueLink.slnx succeeds.
• dotnet test RescueLink.slnx succeeds.

Out of Scope

• Live GPS tracking
• Automatic movement prediction
• Route drawing or heat maps
• Paid SMS, email, or push providers
• Real-time chat
• Frontend implementation unless agreed separately

Before Starting

Please comment with the proposed domain model, endpoint contracts, authorization policy, privacy behavior, migration, duplicate-prevention approach, and planned tests. Wait for confirmation before implementation.

Origin

This feature comes from community feedback describing how reporting exactly where and when a dog was last seen—and whether it was safely contained—helped owners focus their search.