Developer project overview
RoveCheckDeveloper handoff
Version 0.4 | Specification: 3 November 2026 | RoveCheck branding: 5 November 2026
Build a phone-first photo workflow for HOA inspections. Prepare each neighborhood with its name, optional picture, outer map boundary, smaller subarea boundaries, and its own photo tags. In the field, open the camera, take a photo, choose a tag, enter a short description, and save. The photo receives a timestamp and location and is filed to the matching neighborhood and area, with manual confirmation when location cannot identify them reliably. [U4-U5]
Every location reading resolves to one of five named filing cases, LC1 to LC5, defined in section 10. Their names, status labels, tones, order and card layout are part of the specification. [U8]New in 0.4
Reporting can be prepared later in the office. In Inspection Generator, choose a date that has saved photos, then a neighborhood photographed that day, then review its date-filtered photos, descriptions, and categories. The current demo stops at review preparation: no sample document or PDF output yet. The eventual report template will be supplied by the owner. [U5, U7]
Current demo assignment
The main tabs are Capture, Neighborhoods, and Inspection Generator. Capture is phone-first with a simulated photo, tag confirmation, brief description, and Save. Neighborhood details provide Map and category-grouped History. Inspection Generator is date-first and prepares the matching photo review without producing a report. No mandatory inspection session or global Archive navigation is included. [U6-U7]
People and operating model
The same people run the agency and perform inspections. One operator can prepare neighborhoods, capture observations, review photos, and request reports without a forced handoff or agency-versus-inspector role switch. HOA board or customer accounts remain later scope. [U1; T 09:02-09:24]
Renamed RoveCheck on 5 November 2026. The v0.4 feature specification and filing rules remain unchanged.
Versioned change log
- 0.1Initial transcript-based handoff with a session and before-leaving report goal. Those workflow details were superseded in version 0.2. [U3-U5]
- 0.2Camera-first photos without mandatory sessions, mapped subareas, manual location fallback, and later date-based reporting. [U4-U5]
- 0.3Capture, Neighborhoods, and Inspection Generator tabs; Map and category-grouped History within neighborhoods; no global Archive. Generator uses dates with photos, neighborhood cards, and a filtered review gallery. No demo report output; categories remain provisional pending Brock's examples. [U6-U7]
- 0.4Adopts the location filing case system from the showcase demo: five cases, LC1 to LC5, with fixed names, status labels, tones, classification order and card layout (section 10). Adds FR09, the filing case on each photo record, LC acceptance tests and decision D10 on accuracy thresholds. Everything else from version 0.3 is unchanged. [U8]
How to use this handoff
This is a stack-independent developer handoff for comparing implementation proposals. Confirmed requirements and objective acceptance criteria are separated from technical recommendations. The owner will supply the report template and Brock's actual category examples; current demo data and location behavior are simulated. [U7]
Section 10 is a fixed system. Keep its five cases, their wording and their order in every screen and document unless a later version of this handoff changes them. [U8]New in 0.4
1Current scope and delivery boundaries
Confirmed base demo
| Area | Current demo scope |
|---|---|
| Neighborhood setup and details | Neighborhoods tab: name, optional picture, outer and dotted subarea boundaries, and custom tags. Details contain Map and category-grouped History. No global Archive navigation. |
| Capture | Phone camera-first flow without a session. Use a fake demo photo; confirm a tag; enter a brief description; Save with simulated location and timestamp association. |
| Inspection Generator | Third main tab. Show only dates with saved photos; choose a date; show one card per neighborhood photographed that day; open its date-filtered photos, descriptions, and categories. No sample document or PDF output. |
| Location filing cases New in 0.4 | Every capture resolves to one of the five filing cases in section 10 and shows that case's status label. The demo simulates a reading for each case. |
Label the fake photo, simulated coordinates, and simulated associations clearly. Demonstrate a clear location match and manual fallback. The demo proves the requested interactions, not live camera, GPS accuracy, storage durability, authentication, or report generation. [U7] From version 0.4, demonstrate all five filing cases, LC1 to LC5. [U8]
Eventual product reporting
- Save each photo to the neighborhood and relevant subarea identified by location, or by manual choice when the location match is unavailable or ambiguous. [U5]
- Keep captured originals in the library, reached through each neighborhood's History view. Review can exclude a photo from a report without deleting the original. [T 03:54-04:35; U6]
- After a report template is provided and output scope is approved, turn the reviewed neighborhood-and-date photo selection, observations, and actions into the final report. The current demo must not create a sample document or PDF. [U5, U7]
Later features remain separate
Interactive photo pins, historical asset comparisons, customer portals, and automatic urgent notifications remain expansion ideas. Neighborhood Map and History views, subarea filing, and category-grouped photo history are current scope. This History view does not imply a customer portal. [U4-U6; T 08:28-10:48]
Not assumed
No AI photo tagging, diagnosis, invoicing, bidding, dispatch, migration, public links, automatic email distribution, or native app-store release is included by default. Tags are selected manually. Landscaping, Maintenance, Safety, and Cleanliness are provisional; support custom tags and confirm the actual set with Brock. [U5-U6]
This specification is independent of the demo's technology or hosting. Developers may propose their own stack, with tradeoffs for phone usability, camera and location access, storage, offline recovery, maintenance, and eventual report generation. No requirement mandates reuse of the demo stack.
2Confirmed setup and capture workflow
Prepare a neighborhood
Create the neighborhood before fieldwork. Enter its name, optionally add a picture, draw the outer boundary on a map, and draw smaller subarea boundaries within it. Show the smaller boundaries with a dotted treatment so they can be distinguished from the neighborhood outline. Configure photo tags for this neighborhood. [U2, U4-U5]
Proposed detail: give each subarea a readable label for photo filing and manual selection. Store geometry separately from its visual style. Validate that each subarea belongs to its neighborhood, and define how overlaps and areas with no subarea should behave.
Keep spatial areas separate from tags
A subarea describes where a photo belongs on the map. A tag describes its selected category; History groups photos by that category. A landscaping photo may belong to a pool-area boundary. Keep geographic areas and categories separate. [U4-U6]
Open the camera and take a photo
The phone flow starts with the camera experience. The operator does not have to create or start an inspection session first. In the base demo, taking a picture produces the requested fake demo photo. In production, the supported device camera captures the actual image. [U4-U5]
Choose a tag and add a description
In the current demo, the operator confirms a neighborhood-specific tag, writes a short description, and saves. Eventually, time and location should associate a photo with its neighborhood and subarea and may suggest a category when the configured association is unambiguous. The operator must still be able to confirm or change the tag. [U5, U7]
Proposed detail: use explicit area-to-category configuration for any automatic category suggestion; do not assume every subarea has one category. When the match is missing or ambiguous, request manual neighborhood, area, and tag confirmation. No AI image classification is required.
Save metadata and file the photo
The save records the photo, selected tag, description, automatic timestamp, and available location. Associate it with the neighborhood and subarea containing that location. When location is missing, uncertain, or between boundaries, the operator can choose the neighborhood and area manually. This fallback is approved. [U5]
Every save resolves to exactly one filing case from section 10, and that case is stored with the photo. [U8]New in 0.4
Proposed detail: display the destination before or immediately after Save, mark whether it was automatically matched or manually selected, and allow correction. Do not claim that GPS always identifies the correct property or subarea. Preserve the captured coordinates and accuracy separately from the chosen filing destination.
3Functional requirements for development
The product outcomes are confirmed. Detailed validation, storage, and state behavior below are proposed implementation rules for review.
| ID | Capability | Required outcome and proposed detail |
|---|---|---|
| FR01 | Neighborhood setup | Save a neighborhood name and optional picture. Draw and edit its outer boundary. Manage its own custom photo tags. |
| FR02 | Subarea setup | Draw smaller subarea boundaries within the neighborhood and display them dotted. Proposed: readable labels, stable IDs, validation, and geometry versions. |
| FR03 | Camera first capture | Take a photo without a mandatory session. The base demo uses a fake image. Production handles camera permission and interruption without losing saved work. |
| FR04 | Tag and description | Confirm a neighborhood-specific tag, add a short description, and Save. Current demo selection is manual; eventual unambiguous configured category suggestions still allow confirmation or correction. |
| FR05 | Metadata and routing | Record timestamp and available location. File to the matching neighborhood and subarea. Use the approved manual choice when location cannot reliably resolve the destination. |
| FR06 | Neighborhood History and review | Open photos through neighborhood details, which provide Map and History. Group History photos by neighborhood tag; retain date filtering and report exclusion without deleting originals. Remove global Archive navigation. |
| FR07 | Inspection Generator | Third main tab: list only dates with saved photos, then distinct neighborhood cards for that date, then matching photos with descriptions and categories. Current demo prepares review only. |
| FR08 | Eventual report output | Future scope after the owner provides the template: generate a reviewed PDF with frozen inputs, versions, and safe retries. No sample document or PDF generation in the current demo. |
| FR09 New | Location filing cases | Resolve every reading into exactly one of LC1 to LC5 with the ordered rules in section 10.2. Show the case's status label and map, store the case and its candidates with the photo, and keep case names, order, labels and tones identical on every screen. |
Rules to settle with the owner
- Whether every photo requires a subarea when it is inside the outer boundary but outside all smaller boundaries. Proposed default: keep it in the neighborhood with an explicit No subarea state. This is filing case LC4 in section 10.
- Whether a tag and description are mandatory, and whether the interface offers a remembered tag. The demo must show manual selection and a description regardless.
- Whether observations and action items belong to each photo, each report section, or both. Keep the data editable and confirm presentation against the draft report template.
Do not impose a five-word or ten-word limit, a fixed five-tag maximum, a mandatory monthly session, or a same-day report deadline. The meeting's short-note and photo-volume examples are useful test inputs, not approved limits. [T 04:14-04:35, 05:21-05:43, 07:09-07:52; U5]
4User stories and acceptance for field work
These are proposed testable acceptance criteria for the latest confirmed workflow. The same operator can complete all of them.
US01 Prepare the neighborhood and areas
As an operator, I can set up a neighborhood before fieldwork so its map and tags are ready.
- Save the neighborhood name, optional picture, boundaries, and tags. Reopen its details to Map and History; History groups only that neighborhood's photos by configured category. No global Archive navigation is shown.
- Invalid geometry is explained rather than silently accepted. Editing one neighborhood's areas or tags does not change another neighborhood.
- The interface distinguishes a spatial subarea from a photo tag. Proposed labels make manual area selection understandable.
US02 Take a photo without starting a session
As an operator, I can open the phone interface and take a photo immediately.
- The first capture flow does not require Start session, inspection creation, or report setup. Captures are individually saved records.
- The base demo returns a clearly fictional photo from its capture action. It does not ask for live camera access merely to simulate the flow.
- Production camera denial or cancellation leaves existing photos intact and provides a clear recovery path.
US03 Confirm the correct location
As an operator, I can use automatic filing when location is clear and choose manually when it is not.
- With a reliable location match, show the neighborhood and subarea determined from their boundaries. Record coordinates and any available accuracy value.
- With denied, missing, low-confidence, or ambiguous location, allow manual neighborhood and area selection. Do not silently file to the nearest boundary.
- A manual override is recorded as manual. The original coordinates are not rewritten to pretend they proved that choice.
- Each reading shows exactly one filing case, LC1 to LC5, with its fixed status label and map, as defined in section 10. New in 0.4
US04 Tag, describe and save
As an operator, I can choose a tag, describe the photo, and save it with automatic metadata.
- The tag dropdown uses the resolved neighborhood's tags. The selection and description persist, and the saved photo appears under that category in the neighborhood's History.
- Save records a timestamp, available location, and the chosen neighborhood and area. Show whether the record is stored locally, uploading, or synchronized.
- Repeated Save taps and retried uploads do not create duplicate photos. Reopening the saved record shows its data and filing destination.
5User stories and acceptance for reports
US05 Prepare a date-filtered inspection review
As an operator, I can use Inspection Generator to find saved photos for a day and neighborhood without creating a report yet.
- The date list contains only dates with saved photos. Selecting a date shows exactly one card for each neighborhood photographed that date, with no unrelated neighborhoods.
- Selecting a neighborhood card opens only its photos from the selected day, each with description and category. Use an agreed timezone; late upload must not silently change the capture day.
- Changing the date clears stale neighborhood selection. Empty results are explained. The demo exposes no sample-document or PDF-generation output. Test with two dates and multiple neighborhoods.
US06 Review without losing originals
As an operator, I can remove an unnecessary photo from a report while keeping the library evidence.
- The selected neighborhood and date populate the draft automatically. I can review observations and recommended actions, correct tags, and exclude photos.
- Exclusion changes only that report's selection. The original photo, description, timestamp, and location remain available in the library.
- Re-inclusion restores the photo to the draft. Total, included, and excluded counts reconcile.
US07 Generate a report in a later phase
As an operator, once report output is in scope and the template is supplied, I can generate a reviewed PDF. These criteria are not current demo requirements.
- The PDF contains the selected photos, reviewed observations and actions, correct neighborhood and report date, and the approved template version.
- Duplicate submission attempts create one report version for the same request. Ready means that the PDF exists and can be opened.
- Proposed correction rule: a new submission after edits creates a new report version. Earlier generated PDFs and original photos remain unchanged.
US08 Recover saved work
As an operator, I can recover after a connection loss, app restart, or generation failure.
- For the agreed device and offline scope, saved photos and metadata survive tested interruptions. Unsynchronized items remain visible and retryable.
- Generation failure preserves the selected report inputs. A retry uses the same reviewed snapshot rather than silently adding newly uploaded photos.
- If new matching photos arrive after a report selection is frozen, show that more photos are available and let the operator refresh deliberately.
End-to-end release test
Current demo test: save photos across two dates and two neighborhoods; verify Map and category-grouped History; verify dates with photos only, distinct neighborhood cards, and exact date-and-neighborhood gallery contents. Confirm no global Archive or mandatory session and no sample document or PDF output. Walk all five filing cases, LC1 to LC5, and confirm each shows its fixed status label. Added in 0.4 Future report acceptance follows the supplied template.
6Screen structure and report behavior
Base demo screens
| Screen | Main actions and visible states |
|---|---|
| Neighborhoods | Name, optional picture, outer and dotted subarea boundaries, and custom tags. Details offer Map and History; History groups photos by category. Remove global Archive navigation. |
| Capture | Camera-first presentation with a fake-photo capture action. No mandatory session or report creation step. The filing destination card shows the filing case status label, its code and name, and the map with the reading (section 10). Added in 0.4 |
| Inspection Generator | Third main tab: available photo dates, then distinct neighborhood cards for that day, then a date-filtered gallery showing photo, description, and category. Review preparation only; no sample report or PDF output. |
Eventual reporting and expanded History controls
| Screen | Main actions and visible states |
|---|---|
| Neighborhood History | Within neighborhood details, group saved photos by category. Filter by date and optionally subarea; inspect metadata and upload status; correct filing without deleting originals. No separate global Archive screen. |
| Reviewed photo selection | Carry the Inspection Generator date-and-neighborhood selection into future report review. Show selected photos, timezone, pending uploads, and inclusion choices. Do not add report output to the current demo. |
| Future report output | After the actual template and scope are approved, review observations, actions, and exclusions; generate a versioned PDF; show progress, failure, and authorized open or download actions. |
Report content pending the draft template
Brock will provide the actual example report and tags. Landscaping, Maintenance, Safety, and Cleanliness are provisional, with custom neighborhood tags supported. The meeting described a cover, vendor information, summary, actions, categorized photos, and commentary; confirm the final format against Brock's example. [T 01:23-01:48, 07:13-07:30; U6]
Confirm branding, required metadata, category ordering, use of subarea labels, photo density, description and action placement, timestamps, page numbers, empty sections, and any cross references. Subarea filing does not by itself require an interactive map or map image in the PDF.
PDF acceptance to validate
- Photo orientation and detail remain readable. Captions stay with the correct image; long notes wrap without clipping; sections and page numbers remain consistent.
- The PDF includes only the reviewed selection. It contains no excluded images, other neighborhoods' data, unsaved changes, or broken placeholders.
- The chosen report date and generation date remain distinct. A later office-generated report can accurately describe photos captured on the selected day.
7Proposed photo-based data model
The core record is a saved photo with its own metadata and filing destination. A required inspection session is not part of this model. Grouping for a report happens through neighborhood and date selection.
| Entity | Key fields and relationships |
|---|---|
| Organization and operator | Organization ID; operator ID; authentication subject; membership. The same operator can manage neighborhoods, capture photos, and request reports. |
| Neighborhood | ID; organization ID; name; optional picture asset; reporting timezone; active state; current boundary version. Owns subareas and custom tags. |
| Boundary and subarea | Stable area ID; neighborhood ID; readable label; geometry version; polygon; parent neighborhood boundary; created by and at. Store dotted display style separately from geometry. |
| Neighborhood tag | ID; neighborhood ID; display name; order; archived state; revision. A tag is not a geographic area. Preserve historical label snapshots where used in reports. |
| Photo asset | ID; original storage key; checksum; media type; dimensions; captured time and offset; saved and uploaded times; coordinates and accuracy when available; upload status. |
| Photo record | Photo ID; neighborhood ID; optional subarea ID; tag ID; description; observation and recommended action if present; boundary version used; filing case (LC1 to LC5) and candidate area IDs; manual override; revision. Changed in 0.4 |
| Report request | ID; neighborhood ID; selected calendar date; reporting timezone; resolved time interval; selected photo IDs; inclusion choices; reviewed text; source revisions; request status. |
| Report version | ID; request ID; version; immutable input snapshot; template version; PDF storage key; generation status and time; checksum; supersedes report ID. |
| Sync and audit records | Operation ID; entity ID; base revision; actor; timestamp; outcome. Track routing corrections and report submissions without logging photo contents or secrets. |
Data invariants
- A photo's subarea and tag must belong to its chosen neighborhood. Enforce compatible organization access on the server.
- Keep original location evidence separate from the filing choice. Historical photos do not silently move when a map boundary is edited.
- The filing case and its candidates are recorded at capture and are not recomputed when a boundary changes. A manual correction changes the destination and is recorded as manual; it does not change the recorded case. New in 0.4
- Use capture time for date selection, with an agreed timezone; keep save and upload times separately. Handle missing or questionable metadata visibly.
- Report exclusion never deletes a photo asset. Generated reports use frozen photo IDs, text, labels, and template versions rather than live mutable data.
8Proposed services and API contracts
Use an authenticated application API, media storage, and a PDF generation worker as a starting design. These are illustrative contracts, not existing endpoints or a technology commitment.
| Operation | Proposed contract and behavior |
|---|---|
| GET or POST /neighborhoods | List authorized neighborhoods or create one with name, optional picture reference, and reporting timezone. Return stable IDs and revisions. |
| PUT /neighborhoods/{id}/map | Validate and save the outer boundary and subarea geometry. Require the expected revision; return stable area IDs and geometry versions. |
| PUT /neighborhoods/{id}/tags | Create, rename, reorder, or archive tags. Preserve tag IDs and historical report labels. |
| POST /location-match | Accept available coordinates and accuracy; return the filing case (LC1 to LC5), candidate neighborhood and subarea matches, and uncertainty. Do not silently choose an ambiguous result. Changed in 0.4 |
| POST /photos/upload | Authorize an upload for a stable client photo ID. Restrict type and size; return a short-lived upload target. The neighborhood can be confirmed separately. |
| POST /photos | Save or finalize photo metadata, chosen tag, description, automatic times, available location, filing case, and confirmed neighborhood and area. Use an operation ID. |
| PATCH /photos/{id} | Correct filing, tag, description, or action text with a base revision. Record manual overrides and reject conflicting updates rather than overwrite silently. |
| GET /photos | Derive dates with saved photos and distinct neighborhoods for a selected day; filter gallery photos by both neighborhood and date. Use the agreed timezone and return description, category, and upload status. |
| POST /report-requests | Resolve neighborhood and date into a reviewable photo set. Save selected IDs, inclusion choices, reviewed text, and source revisions. |
| POST /report-requests/{id}/generate | Validate assets; freeze inputs; enqueue PDF generation using an idempotency key. GET /reports/{id} returns Pending, Ready, or Failed. |
Saving and generating safely
Proposed save sequence: preserve the original image and its metadata locally or on the server; resolve or manually confirm neighborhood and area; validate the tag; persist the photo record; show its actual storage state. A successful UI message must distinguish local save from server synchronization.
Proposed report sequence: select neighborhood and day; resolve and review the eligible photo set; confirm included assets are available; freeze that set and its text; generate and verify the PDF; mark Ready. Later uploads do not silently change the frozen selection. Excluded and unselected originals remain protected in the library.
9Location matching and offline behavior
Location matching with an approved fallback
Automatic neighborhood and subarea filing is the desired default. Manual selection is confirmed for missing location or ambiguous boundaries. Location readings can be denied, unavailable, stale, or too imprecise for small areas; the product must communicate uncertainty rather than promise exact GPS accuracy. [U5]
The five location cases and their behavior are now specified as a fixed system in section 10, Location filing cases. That section replaces the case table from version 0.3. [U8]
Offline capture is a production decision
The later office-report workflow removes the earlier requirement to complete a PDF before leaving. It does not remove the risk of losing photos when connectivity is poor. Recommended baseline: evaluate durable local capture and queued synchronization, with report generation on the server after the necessary photos are available.
- Write image and metadata before acknowledging local Save. Persist queues across supported restarts, retry safely, and verify checksums.
- Cache neighborhood boundaries and tag sets only under an agreed offline design. If current mapping data is unavailable, request confirmation instead of claiming a reliable match.
- Show local, uploading, synchronized, and failed states. Preserve originals until server acknowledgement and the agreed local-retention policy permit cleanup.
- Use revisions for edits and surface conflicts. A changed boundary must not silently reroute previously saved photos or change existing reports.
Device validation
Test intended phone and tablet browsers or app runtimes for camera access, geolocation permission, stale coordinates, accuracy handling, backgrounding, restart recovery, storage limits, and lost authentication. Agree on capacity and supported conditions before promising offline behavior. Use representative photo volumes, including the meeting's approximately 200-photo example, as tests rather than a committed limit. [T 04:14-04:35]
10Location filing cases New in 0.4
Every photo save classifies its location reading into exactly one of five filing cases. The cases, their order, names, status labels, tones, classification rules and card layout come from the showcase demo and are adopted here as part of the specification. They are not proposals: keep them as written in every screen, document and test. [U8]
10.1 The five cases
| Code | Case name | Status label | When it applies | What the app does | What is recorded |
|---|---|---|---|---|---|
| LC1 | Clear match | Filed automatically | Inside a neighborhood's outer boundary, and exactly one subarea contains the reading or lies within its accuracy radius. | Files to that neighborhood and subarea. The operator can still change it. | Coordinates, accuracy, boundary version, method auto. |
| LC2 | Boundary edge | Asks to confirm | Inside the outer boundary, and two or more subareas lie within the accuracy radius, including overlapping subareas. | Offers the candidate areas and blocks Save until one is chosen. Never picks the nearest. | Reading, all candidate area IDs, the choice, method manual. |
| LC3 | No location | Manual choice | No usable reading: permission denied, no signal, stale, or accuracy worse than the agreed threshold (D10). | The operator chooses the neighborhood and area. | Location missing, or the imprecise reading as captured. No coordinates are invented. Method manual. |
| LC4 | Inside, no subarea | No subarea | Inside the outer boundary, and no subarea lies within the accuracy radius. | Files to the neighborhood with an explicit No subarea state. The operator may pick an area instead. | Coordinates, accuracy, boundary version, method auto. |
| LC5 | Outside all neighborhoods | Asks, never guesses | The reading falls outside every configured outer boundary. | Asks which neighborhood was meant, or points to setup. Nothing is preselected. | Coordinates, accuracy, the choice, method manual. |
10.2 How a reading is classified
Apply these rules in order. The first rule that matches decides the case.
- No usable reading, or accuracy worse than the agreed threshold: LC3 No location. The demo uses 30 m as a placeholder until D10 is settled.
- The reading is outside every configured outer boundary: LC5 Outside all neighborhoods. Proposed: when the accuracy circle crosses a neighborhood's outer boundary, ask to confirm the neighborhood the same way as LC2 (D10).
- Count the subareas that contain the reading or lie within its accuracy radius:
- exactly one: LC1 Clear match
- two or more: LC2 Boundary edge
- none: LC4 Inside, no subarea
The classification never chooses the geographically nearest area or neighborhood. The demo implements these rules in matchLocation() in assets/data.js.
10.3 Status labels and tones
Each case has one status label and one tone. The tone colors the label and the GPS indicator dot in Capture. Use the product's semantic colors (positive, caution, information, critical), never a one-off color, and never show the color without the words.
- Positive (green): LC1 Filed automatically
- Caution (amber): LC2 Asks to confirm, LC3 Manual choice
- Information (blue): LC4 No subarea
- Critical (red): LC5 Asks, never guesses
10.4 Case card
Where the cases are explained, as on the showcase and in this handoff, each case is a card with the same five parts in the same order.
- Map panel at 4:3, zoomed around the reading to about 240 m across. The outer boundary is a solid line, subareas are dotted, the reading is a dot with a ring, and the accuracy circle is drawn to scale. LC3 shows the whole neighborhood muted with the words "No location reading" and no dot.
- Status pill with the case's label and tone.
- Case name in the display face, uppercase.
- One sentence on what the app does in that case.
- Try it link to the matching situation in the field preview.
Cards always appear in LC1 to LC5 order. On wide screens they sit in one row of five. On narrower screens they wrap into columns at least 230 px wide, so three then two, and on phones they stack in one column. The order never changes.
10.5 Where the system appears
| Surface | What it shows |
|---|---|
| Showcase, "Where does the photo go?" | The five case cards. |
| Field preview, field situations | One situation per case, in case order: case name, example location, code and status label. |
| Capture, filing destination card | Status pill, case code and name, the map with the reading, then the next step: a confirmed destination, the candidate areas, or the neighborhood and area pickers. |
| Capture, simulated GPS (demo only) | The five situations with their tone dots. |
| Photo details | Filing case code, name and status label, next to the filing method and the original reading. |
| This handoff | The definitions, rules and cards in this section. |
10.6 Keeping the system intact
- The five cases cover every reading. Do not add, merge, split, rename or reorder cases, and do not change a status label, tone or case summary, without a new version of this handoff and the owner's approval.
- Define the cases once in code and render every surface from that definition. In the demo this is
FILING_CASESinassets/data.js, and the card is drawn byfilingCaseCard(). - Store the case code on every photo record with its candidates, the original reading and the filing method, so later screens and reports never re-derive it.
- Screens may add instructions next to the status label, such as "2 areas are possible. Confirm one." They never replace the label.
10.7 Acceptance tests
| Test | Given | Expect |
|---|---|---|
| LC1 | A reading on the Willow Creek pool deck at ±5 m. | "Filed automatically", destination Clubhouse & Pool, Save enabled once a tag is chosen, record marked auto. |
| LC2 | A reading on the Main Gate and Dog Park edge at Stonebridge, ±18 m. | "Asks to confirm", both areas offered, Save blocked until one is chosen, record marked manual with both candidates. |
| LC3 | Location permission denied; separately, a reading at ±41 m. | "Manual choice" and pickers in both. No coordinates stored for the denied reading; the ±41 m reading is kept as captured but not used to file. |
| LC4 | A reading inside Willow Creek between the trail and the playground. | "No subarea", filed to Willow Creek as No subarea, with the option to choose an area. |
| LC5 | A reading past the Willow Creek boundary. | "Asks, never guesses", nothing preselected, a pointer to neighborhood setup. |
| LC-all | Every surface in 10.5. | The same five names, labels, tones and order everywhere. No color appears without its label. |
11Security and production quality
These are recommended engineering controls. The authentication method, retention periods, hosting region, access policy, and supported offline behavior remain decisions for the owner and developers.
Private photos and deliberate location use
- Require sign-in and authorize neighborhood, photo, export, and background-job access on the server. Keep photos and PDFs private by default.
- Use encrypted transport, managed encryption at rest, and authorized expiring downloads. Keep secrets out of clients, PDFs, logs, and source control.
- Request location for the photo workflow transparently. Do not extend photo geolocation into continuous background tracking. Permission denial must preserve the manual filing path.
- Record only the location metadata needed for filing and approved evidence. Decide whether exported images retain EXIF location data or use stripped derivatives.
- Avoid unnecessary resident or bystander information. Establish retention, access, correction, recoverable removal, and deletion procedures before rollout.
Protecting originals and history
Excluding a photo from a report does not delete it. Photo deletion must be a separate permissioned action under an agreed retention policy. Preserve original files and stable report snapshots; back up structured records and media; test restoration. Do not invent a retention duration or a guarantee that a local browser will keep files forever.
Proposed release evidence
| Area | Evidence required |
|---|---|
| Capture integrity | Saved images and metadata survive the supported interruptions. Repeated Save and upload retries create no duplicates. |
| Location and filing | Tests cover all five filing cases, LC1 to LC5: a clear match, small-area uncertainty, overlap and boundary edge, missing permission and low accuracy, no subarea, outside all neighborhoods, and a manual correction. Changed in 0.4 |
| Report selection | Tests with multiple dates and neighborhoods prove that only saved-photo dates appear, neighborhood cards are distinct and relevant, and galleries contain exactly the selected day and neighborhood. No demo report output. |
| Device usability | The camera-first flow works without session setup. Neighborhood details provide Map and History; photos group by configured category. No global Archive item is present. Phone controls and status labels remain usable. |
| Access and privacy | Unauthorized users cannot access photos or reports. Location is not collected continuously. Private media cannot be downloaded anonymously. |
| Output and operations | PDFs match the supplied template and reviewed inputs. Failure states, backup restoration, support ownership, and storage monitoring are tested. |
Measure capture-to-save time, failed or manually corrected location matches, upload recovery, and report selection and generation time. Agree on acceptable thresholds during a pilot; no performance or GPS-accuracy guarantees are committed here.
12Delivery roadmap and major risks
Recommended sequence without fixed dates
| Stage | Deliverable and exit condition |
|---|---|
| 1 Update the brief | Review the three main tabs, neighborhood Map and History, category grouping, manual fallback, and date-first review preparation. Compare stack-independent proposals; confirm final tags against Brock's examples. |
| 2 Build the base demo | Demonstrate Capture, Neighborhoods, and Inspection Generator with simulated capture and location data. Verify photo dates, distinct neighborhood cards, and matching review galleries. Do not generate sample documents or PDFs. |
| 3 Validate production choices | Test camera, location, boundary matching, storage, uploads, and permission failures on target devices. Agree the filing-case accuracy threshold (D10). Review Brock's actual example report and tags before finalizing the report template and category defaults. |
| 4 Build the product workflow | After demo review and receipt of the template, scope authenticated photo storage, routing, review, and eventual report generation. Production technology is not constrained by the demo stack. |
| 5 Pilot real use | Test actual field capture and later office reporting with selected operators. Review location corrections, missing photos, report output, and recovery behavior. |
| 6 Release and extend | Resolve pilot issues, establish support and recovery procedures, and then decide whether to add interactive photo pins, historical comparisons, portals, or alerts. |
Risks and controls
| Risk | Recommended control |
|---|---|
| Small areas exceed GPS precision | Show uncertainty and the approved manual fallback through the filing cases in section 10. Keep location evidence separate from the filing choice; test boundary and overlap cases. |
| The wrong day or neighborhood is reported | Use explicit neighborhood, calendar date, and reporting timezone. Review the eligible set and handle late uploads without silently changing a frozen report. |
| Capture becomes too complicated | Keep camera entry free of mandatory session setup. Ask only for location clarification when needed; keep tags neighborhood-specific and editable. |
| Original photos are lost | Separate report exclusion from deletion; acknowledge real storage state; verify retries, restart recovery, backups, and restoration. |
| Report layout is invented too early | Wait for the owner's report template and Brock's category examples. Keep provisional tags editable. Current demo stops at photo review preparation and produces no sample document or PDF. |
| Demo is mistaken for a finished system | Label fake images and simulated metadata clearly. Distinguish UI behavior from tested live camera, GPS, storage, authentication, and PDF capabilities. |
| Filing wording drifts between screens New in 0.4 | Define the five cases once in code, render every surface from it, and run the LC-all test in 10.7 before each release. |
Estimate only after the platform, offline scope, location rules, and report template are reviewed. No dates, costs, accuracy guarantees, or fixed capacity commitments are established by this document.
13Open decisions and developer handoff
The current main tabs, neighborhood Map and History, date-first Inspection Generator, and no-output demo boundary are confirmed. Manual fallback is approved. The five filing cases in section 10 are confirmed. The decisions below concern production details and do not block the requested demo.
| ID | Decision | Question to resolve | Needed for |
|---|---|---|---|
| D01 | Report template | What content, branding, photo density, observation and action placement, and pagination are established by Brock's forthcoming example report? | Final PDF output |
| D02 | Devices | Which phones, tablets, browsers, and operating systems are supported? Is a responsive website sufficient for production? | Device testing |
| D03 | Offline scope | Must photos save without a network? How long can they remain local, and what recovery and storage guarantees are supportable? | Capture reliability |
| D04 | Area rules | Are subareas named? Can they overlap? What happens inside a neighborhood but outside all subareas? Can a photo belong to multiple areas? Version 0.4 handles overlaps as LC2 and outside-all-subareas as LC4. | Location routing |
| D05 | Time and dates | What timezone defines a neighborhood's Today and selected day? How are incorrect device times corrected and historical reports preserved? | Report selection |
| D06 | Text and tags | Which actual tags will Brock provide to replace the provisional categories? Are tag and description required? Can photos have multiple tags? Where are observations and actions entered and shown? | Review rules |
| D07 | Access and delivery | Who can access which neighborhoods, and how are PDFs delivered outside the application? Are any external viewers needed in the first release? | Security and sharing |
| D08 | Retention and capacity | How long are originals, local copies, drafts, and report versions retained? What photo volumes and file sizes must be supported? | Storage and operations |
| D09 | Pilot approval | Which operators and neighborhoods will test the product, and who approves capture behavior, location handling, and report output? | Release decision |
| D10 New | Filing thresholds | What accuracy, in meters, makes a reading too imprecise to file automatically (LC3)? Should an accuracy circle that crosses a neighborhood's outer boundary ask to confirm the neighborhood? | Location routing |
Developer deliverables for the next review
- Show Capture, Neighborhoods, and Inspection Generator. Verify Map and category-grouped History, only dates with photos, distinct neighborhood cards, and correctly filtered galleries. No global Archive, mandatory session, sample document, or PDF output in this demo.
- Show all five filing cases, LC1 to LC5, with their fixed names, status labels, tones and order. New in 0.4
- Provide a stack-independent implementation proposal with assumptions, alternatives, maintenance and operating tradeoffs, and estimates. Separate current demo behavior from future production and report-output work.
- Provide objective tests linked to FR01-FR09, US01-US08 and LC1-LC5. Mark future PDF criteria separately; test missing GPS, manual tag confirmation, date changes, duplicate neighborhood cards, filtering, and saved-photo history now.
- Before production handover, document deployment, access controls, backups, recovery, known limits, support ownership, and any approved migration work.
Record later decisions and template feedback in the next version of this handoff. Keep the report snapshot and photo-library model consistent with the camera-first workflow.
14Sources and version precedence
T refers to the Plaud transcript Planning: HOA Inspection App and Reporting Workflow, recorded 2 November 2026, approximately 12 minutes 51 seconds. Recording identifier: of_044fcf5b84af4121d5b8eed9d2247ee1. All 162 transcript segments were reviewed for version 0.1. Elapsed timestamps below remain evidence except where the later owner clarifications supersede the original flow.
| Locator | Continuing evidence or superseded detail |
|---|---|
| T 00:00-02:28 | HOA common-area inspections, current CompanyCam workflow, existing report components, and manual report assembly. |
| T 02:29-04:35 | Field capture and automatic report population; exclusion preserves originals. The original session and before-leaving flow is superseded by U4-U5. |
| T 05:21-07:30 | Community-specific tags, monthly inspection context, descriptions, observations, recommended actions, and possible section placement. |
| T 08:03-08:24 | Reviewing photos and generating a PDF. Timing now follows the later neighborhood-and-date report request. |
| T 08:28-10:48 | Photo pins, historical customer access, and urgent notifications were expansion ideas. Current subarea filing is confirmed separately in U4-U5. |
| T 11:26-12:14 | Request for example reports and discussion of mobile capture, timestamps, descriptions, and actions. The latest camera-first flow governs. |
Project clarifications on 3 November 2026
| U1 | The inspector and agency are the same people. One operator can manage setup, capture photos, and request reports; no invented role split is needed. |
| U2 | Prepare neighborhoods and boundaries before fieldwork, create custom tags, use forthcoming example reports, and produce the developer overview before the preview demo. |
| U3 | Earlier request for a report before the inspector drives away. Superseded by U5; retained here only to make the version change explicit. |
| U4 | Earlier 3 November clarification (under the former Inspector’s Gadget name); neighborhood name and optional picture; outer and dotted subarea boundaries; neighborhood-specific tags; camera-first capture without a mandatory session. |
| U5 | Voice clarifications around 17:46-17:48 UTC: photo, tag, description, Save, timestamp, and location filing; later office reporting by neighborhood and day. Manual neighborhood and area selection was explicitly approved for missing or ambiguous location. |
| U6 | Later project owner clarification on 3 November 2026: remove global Archive navigation; neighborhood details contain Map and History, with photos grouped by category. Landscaping, Maintenance, Safety, and Cleanliness are provisional, alongside custom tags. Brock will provide the actual example report and tags. |
| U7 | Latest 3 November requirements: main tabs Capture, Neighborhoods, and Inspection Generator. Generator shows dates with saved photos, then distinct neighborhoods for the date, then a gallery with photos, descriptions, and categories. No sample document or PDF output in the demo. Current location behavior is simulated; eventual unambiguous associations retain manual fallback and tag confirmation. Deliver a stack-independent handoff with objective tests; the owner will supply the report template and Brock's category examples. |
| U8 New | Request on 3 November 2026 after the showcase review: add the five-case location filing system shown in the showcase ("Where does the photo go?") to the developer handoff, and keep its organization and system. |
Version 0.4 adds U8. Version 0.3 added U6-U7. U4-U5 still supersede the original session and before-leaving flow. Technical details remain proposals except where section 10 fixes the filing case system; actual report and category examples will define the final output.
RoveCheck developer project overview, version 0.4, 3 November 2026. Demo data, photos and coordinates referenced here are simulated.